[concurrency-interest] Using Atomic*FieldUpdater to remove indirection

Ariel Weisberg ariel at weisberg.ws
Thu Feb 14 11:56:15 EST 2013


Hi,



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 [1]volatile field onto a stack variable 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?



Thanks,

Ariel



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
indirection

> >> 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

References

1. https://github.com/VoltDB/voltdb/blob/cow_indirection/src/frontend/org/voltcore/utils/COWMap.java#L52
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130214/24b266d5/attachment-0001.html>


More information about the Concurrency-interest mailing list