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

[√iktor Ҡlang]

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>
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
>



-- 
Cheers,
√
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20141008/7b2bcb62/attachment.htm>