<div dir="ltr">Hi Peter,<br><br>can you quantify: " is almost no additional runtime overhead."?</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 8, 2014 at 11:38 AM, Peter Levart <span dir="ltr"><<a href="mailto:peter.levart@gmail.com" target="_blank">peter.levart@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/05/2014 10:44 PM, Peter Levart wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:<br>
<br>
<a href="http://cr.openjdk.java.net/~plevart/jdk9-dev/AtomicFieldUpdater.AccessChecks/AnonClassPerInstance/AtomicIntegerFieldUpdater.java" target="_blank">http://cr.openjdk.java.net/~<u></u>plevart/jdk9-dev/<u></u>AtomicFieldUpdater.<u></u>AccessChecks/<u></u>AnonClassPerInstance/<u></u>AtomicIntegerFieldUpdater.java</a> <br>
</blockquote>
<br></span>
Hi,<br>
<br>
I experimented further with this.<br>
<br>
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:<br>
<br>
<a href="http://cr.openjdk.java.net/~plevart/jdk9-dev/AtomicFieldUpdater.AccessChecks/AnonClassPerCclass/AtomicIntegerFieldUpdater.java" target="_blank">http://cr.openjdk.java.net/~<u></u>plevart/jdk9-dev/<u></u>AtomicFieldUpdater.<u></u>AccessChecks/<u></u>AnonClassPerCclass/<u></u>AtomicIntegerFieldUpdater.java</a><br>
<br>
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.<br>
<br>
Regards, Peter<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.<u></u>oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/<u></u>listinfo/concurrency-interest</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div><span style="border-collapse:separate;color:rgb(0,0,0);font-family:Times;font-variant:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13.333333969116211px">Cheers,</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13.333333969116211px">√</div></span></div></div>
</div>