[concurrency-interest] Fences, AtomicXFieldUpdater enhancements, and @Racy annotations

Doug Lea dl at cs.oswego.edu
Fri Jan 16 10:24:17 EST 2009


Peter Veentjer wrote:
> Hi Doug,
> 
> can you tell us something about the internals of the atomic field
> updaters? Do they work based on reflection, if yes, what is the
> performance impact?

You can see the current implementation of the int version at
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/atomic/AtomicInteger.java?view=log

(It is possible that some JVMs use a different approach, but
I don't think so -- I think all production JVMs use our code.)

It is established using reflection, but then uses the information
collected to do a bunch of checks on a per-call basis.

The trusted streamlined version of, for example AtomicIntegerFieldUpdater.get
is just:
         public int get(T obj) {
             return unsafe.getIntVolatile(obj, offset);
         }
which does not normally entail even a function call, because of
intrinsification. And the method itself is trivially inlinable, so
almost always is. So, ideally,
   int v = aVolatile
and
   int v = aVolatileUpdater.get(this);
run exactly the same.

> 
> And what is the performance compared to a normal AtomicXXX class?

This is where the footprint, locality and indirection issues come in.
Sometimes it is actually better to offload volatile/atomic
operations to a little stand-alone object, but more often it isn't.
Ignoring these, the performance of
   int v = anAtomicInteger.get()
should be about the same with respect to the get() operation
itself (i.e., ignoring the indirection).

-Doug




More information about the Concurrency-interest mailing list