[concurrency-interest] Using Atomic*FieldUpdater to remove indirection
vitalyd at gmail.com
Thu Feb 14 12:31:13 EST 2013
Yes reading volatile into a temp will get you a register/stack slot.
To be safe, you should pad before and after. No guarantees on object
layout but you can take advantage of knowing hotspot's default layout
(fields laid out in increasing representation size, references last I
Arrays are contiguous blobs of memory but are heap allocated separately
(they're not embedded in the object itself but referenced).
Sent from my phone
On Feb 14, 2013 11:59 AM, "Ariel Weisberg" <ariel at weisberg.ws> wrote:
> I only need this to work on x86_64 so I should be fine with volatile reads
> of references. The only path that has to be fast is reading the field,
> updating can be slow (and is).
> Will storing the volatile field onto a stack variable<https://github.com/VoltDB/voltdb/blob/cow_indirection/src/frontend/org/voltcore/utils/COWMap.java#L52> give
> me a snapshot of the value?
> Another question I have is about the padding suggestion. I looked at how
> it is done in Exchanger with the 15 long fields. What guarantees are there
> for field ordering and alignment of the allocated object WRT to cache
> lines? It seems like you might need to pad both before and after the field
> that is contended.
> Is there a difference between storing a reference to a properly padded
> object for contended fields vs adding the padding directly to the object
> containing the contended field? What about array fields (primitives, and
> objects), are they ever stored inside the object or are they always
> separate allocations?
> On Thu, Feb 14, 2013, at 11:15 AM, Chris Dennis wrote:
> > My understanding is that doing that is not technically (per the JDK spec)
> > safe. The updaters don't guarantee atomicity of their changes with
> > respect to other mutations. On Hotspot I think you can only see this
> > behavior for AtomicLongFieldUpdater when the underlying hardware lacks an
> > 8 byte compare-and-swap (which obviously makes sense).
> > On Feb 13, 2013, at 10:37 PM, Aaron Grunthal wrote:
> > > Btw, Atomic*Updaters are not entirely equivalent to raw volatile/CAS
> accesses due to a bunch of security checking they do. Especially when
> security domains are used or the Updater's target class has subclasses then
> it has to do some checks that the JVM cannot optimize away. So if every
> ounce of performance counts you probably should do volatile reads and
> writes to the field handled by the updater directly and only use it for
> CAS. And as last resort there's also Unsafe, but there usually are bigger
> fish to fry before you get to that point.
> > >
> > > On 13.02.2013 21:41, Ariel Weisberg wrote:
> > >> Hi,
> > >>
> > >> Does it make sense to use Atomic*FieldUpdater to remove the
> > >> overhead of an AtomicLong and AtomicReference? Similarly, does it make
> > >> sense to use Atomic* to create indirection in order to avoid false
> > >> sharing?
> > >>
> > >> Thanks,
> > >> Ariel
> > >> _______________________________________________
> > >> Concurrency-interest mailing list
> > >> Concurrency-interest at cs.oswego.edu
> > >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> > >>
> > >
> > > _______________________________________________
> > > Concurrency-interest mailing list
> > > Concurrency-interest at cs.oswego.edu
> > > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest