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

Peter Levart peter.levart at gmail.com
Thu Oct 9 05:52:43 EDT 2014

On 10/08/2014 05:41 PM, Vladimir Ivanov wrote:
>> Just by moving the nested
>> AtomicIntegerFieldUpdater.AtomicIntegerFieldUpdaterImpl class to
>> java.lang.invoke package, annotating the final instance fields 'tclass',
>> 'cclass' and 'offset' with @Stable annotation and simplifying the
>> invocation check, I get the same benchmark results. Why are those JVM
>> pearls so hidden in the java.lang.invoke package?
> Mostly because they are not ready for prime time yet.
> There's a draft proposal for "lazy final" fields [1], but it hasn't 
> been submitted officially yet. It covers part of the functionality 
> provided by @Stable (fields, but not arrays).
> Best regards,
> Vladimir Ivanov
> [1] http://cr.openjdk.java.net/~jrose/draft/lazy-final.html

That's great. I can see that there are two points encapsulated in this 
lazy finals proposal. One is the lazy assignment that can occur any time 
after constructor, restricted perhaps only to code of the declaring 
class, and the other is that such fields are *really* final, or in other 
words @Stable, meaning they can not be assigned twice, not even with 
reflection, which enables compiler optimizations. It's a little odd that 
in order to achieve *really* final behaviour and consequently better 
optimization, you would have to give up on  the definitive assignment 
rules help from javac.

But what about this idea:

Reflection supports updating ordinary final instance fields (via 
privileged setAccessible(true)) in order to achieve just what the lazy 
final fields are trying to achieve - lazy initialization outside 
constructor. Mainly to support Java  and other kinds of 
deserializations. I would say that any other uses of setAccessible(true) 
which assigns final field more than once are rare or non-existent. So 
why not making ordinary instance final fields *really* final by treating 
them in reflection as lazy final fields with a little tweak - the 
assignment of null/zero value to an "unassigned" field would not throw 
exception, but just be a NOOP - leave the field in "unassinged" state.

This way deserialization of ordinary final fields would still work, but 
VM compiler could treat them all as @Stable, immediately optimizing huge 
codebases on a different level.

Am I not seeing something in that simplified picture?

Regards, Peter

>> Now let me try to get something similar from 
>> AtomicReferenceFieldUpdater...
>> Regards, Peter
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list