[concurrency-interest] lazy finals - was: Here's why Atomic*FieldReference access checking is broken
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 , 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
>  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?
>> Now let me try to get something similar from
>> Regards, Peter
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest