[concurrency-interest] Here's why Atomic*FieldReference access checking is broken

Remi Forax forax at univ-mlv.fr
Wed Oct 8 08:33:56 EDT 2014

The code generates a different class for each field updater,
so in that case the ccClass (the type of the field) is considered as a 
so the instanceof check can be removed by the JIT.

Usually, it's not a good idea to do that because you trade a constant 
argument for
a non constant implementation of the interface Atomic*FieldUpdater, but 
that the updater are usually static final, i.e. a constant for the JIT,
here, it should be faster.

Peter, in term of implementation, you can use the fact that you can patch
the class when you call defineAnonymous class, so you can insert the 
offset and the class,
without using a thread local which is really a hack.

There is another way to do exactly the same things, make ccClass 
constant foldable for
the JIT without asking to load a bunch of classes. The implementation of 
the Updater
can be moved into java.lang.invoke and use the annotation @Stable, in 
that case,
the field ccCache will be considered as constant if the updater is 
constant itself,
this trick doesn't come from me but from Paul Sandoz which currently 
works on
this area as Doug mention.


On 10/08/2014 12:23 PM, √iktor Ҡlang wrote:
> Hi Peter,
> can you quantify: " is almost no additional runtime overhead."?
> On Wed, Oct 8, 2014 at 11:38 AM, Peter Levart <peter.levart at gmail.com 
> <mailto:peter.levart at gmail.com>> wrote:
>     On 10/05/2014 10:44 PM, Peter Levart wrote:
>         The 3rd report shows a result of experimental
>         AtomicIntegerFieldUpdater implementation which loads new
>         VM-anonymous class for each new instance which allows VM
>         compiler to specialize code for a particular field. Such
>         implementation is nearly as fast as Java field access. This is
>         just a proof of concept. A little hack-ish, doesn't include
>         the fix for the overly restrictive protected access yet, but
>         here it is if anyone is interested:
>         http://cr.openjdk.java.net/~plevart/jdk9-dev/AtomicFieldUpdater.AccessChecks/AnonClassPerInstance/AtomicIntegerFieldUpdater.java
>         <http://cr.openjdk.java.net/%7Eplevart/jdk9-dev/AtomicFieldUpdater.AccessChecks/AnonClassPerInstance/AtomicIntegerFieldUpdater.java>
>     Hi,
>     I experimented further with this.
>     It seems that making 'offset' a static final field is not
>     necessary to get optimal performance out of specialized
>     one-class-per-instance Atomic*FieldUpdater. Only the 'cclass'
>     field used in check matters. So 'offset' can be pushed up to
>     abstract Atomic*FieldUpdaterImpl as a final instance field. Now
>     that specialized subclass of Atomic*FieldUpdaterImpl is only
>     'cclass' specific, it can be shared among instances that use the
>     same 'cclass'. That means only one VM-anonymous subclass per
>     target class (or subclass/caller of target class when protected
>     access is involved). The VM-anonymous subclass is cached using
>     ClassValue:
>     http://cr.openjdk.java.net/~plevart/jdk9-dev/AtomicFieldUpdater.AccessChecks/AnonClassPerCclass/AtomicIntegerFieldUpdater.java
>     <http://cr.openjdk.java.net/%7Eplevart/jdk9-dev/AtomicFieldUpdater.AccessChecks/AnonClassPerCclass/AtomicIntegerFieldUpdater.java>
>     I seems that with such Atomic*FieldUpdater there is no compelling
>     reason to use Unsafe directly as there is almost no additional
>     runtime overhead. The only method that is about 30% slower than
>     Java counterpart is get(), but there's hardly a reason to use it
>     instead of simple Java volatile field read.
>     Regards, Peter
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> -- 
> Cheers,
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141008/024873fb/attachment.html>

More information about the Concurrency-interest mailing list