Hi Peter, can you quantify: " is almost no additional runtime overhead."?
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 > -- Cheers, √
