On 10/08/2014 12:23 PM, √iktor Ҡlang wrote:
Hi Peter,
can you quantify: " is almost no additional runtime overhead."?
Limited to AtomicIntegerFieldUpdater, all individual modifying
operations that map directly to Unsafe intrinsics benchmarked with JMH
tests run at same speed as normal Java volatile write of int field.
Thanks to Doug for pointing me to Paul Sandoz's J1 slides about
VarHandles, I'll do some more tests... I have checked the slides and
will try to do some benchmarks comparable to those done by Paul. I can
see Paul is comparing VarHandles to AtomicReferenceFieldUpdater which
will be harder to make as performant since it not only has to do a type
check on target reference, but also on the value that is written to
memory location (the type of object reference).
Regards, Peter
On Wed, Oct 8, 2014 at 11:38 AM, Peter Levart <peter.lev...@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
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
_______________________________________________
Concurrency-interest mailing list
concurrency-inter...@cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
