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

[Peter Levart]

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.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
>>>
>> 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-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
>