RFC (S) 8140483: Atomic*FieldUpdaters final fields should be trusted
Volker Simonis
volker.simonis at gmail.com
Mon Oct 26 18:01:31 UTC 2015
Hi Aleksey,
this is a nice little change with good performance improvements.
However, I already see the list of exceptions in
trust_final_non_static_fields() growing longer and longer :)
Maybe a new annotation "@TrustNonStaticFinalFields" would be the
better solution? It should be public (but not necessarily in the
standard java name space) to allow users to annotate their code and
profit from such optimizations as well.
We could also avoid adding an annotation and instead just introduce a
new option like
-XX:TrustNonStaticFinalFieldsIn=<classname|packagename>. This would
have the charm of not polluting the code with non-standard
annotations. And it could be of type 'ccstrlist' (i.e. 'accumulating
string argument') and pre-initialized with packages like
"java/util/concurrent/atomic". Extending -XX:CompileCommand with
something like a 'trustnonstaticfinalsin <class>' option would be just
another flavour of this approach.
Both these proposals would give people the chance to experiment with
this optimization without having to recompile HotSpot.
What do you think?
Volker
On Mon, Oct 26, 2015 at 3:14 PM, Aleksey Shipilev
<aleksey.shipilev at oracle.com> wrote:
> Hi,
>
> I would like to gauge interest in doing a simple VM change that
> significantly improves the performance of Atomic*FieldUpdaters:
> https://bugs.openjdk.java.net/browse/JDK-8140483
>
> In short, we are looking into folding away the checks in A*FU:
>
> private final Class<T> tclass;
> private final Class<?> cclass;
>
> public final int get(T obj) {
> if (obj == null || obj.getClass() != tclass || cclass != null)
> fullCheck(obj);
> return unsafe.getIntVolatile(obj, offset);
> }
>
> Since most use cases for A*FU involve putting them into static final
> fields, the Updater instances are known constants. Now, the internal
> instance final fields are not trusted by default. This can be "fixed"
> with -XX:+TrustNonStaticFinalFields -- the bad thing about this option
> is that it's global, and it may break user code. Vladimir I. has a
> potential improvement that handles this by tracking the final field
> writes, but there is no clear ETA for that feature.
>
> With this little VM improvement, we can close the gap for A*FU, and
> eliminate another reason for using Unsafe today:
> http://cr.openjdk.java.net/~shade/8140483/webrev.00/
>
> It improves the generated code and performance significantly:
> http://cr.openjdk.java.net/~shade/8140483/notes.txt
>
> Thanks,
> -Aleksey
>
More information about the hotspot-compiler-dev
mailing list