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

[Peter Levart]

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 
>

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

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