[concurrency-interest] Here's why Atomic*FieldReference access checking is broken
viktor.klang at gmail.com
Wed Oct 8 06:23:33 EDT 2014
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>
> 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:
> 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:
> 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
> Regards, Peter
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest