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
