RFC (S) 8140483: Atomic*FieldUpdaters final fields should be trusted

Remi Forax forax at univ-mlv.fr
Mon Oct 26 22:37:58 UTC 2015

Hi Aleksey,
there is another solution,

Put the implementation of ARFU inside java.lang.invoke, it will be a mess in term of maintenance for Doug and Martin, but fields of classes in java.lang.invoke are always trusted and as a bonus you have access to nice annotations like @ForceInline. 

Taking a look to the generated assembly, I wonder why the obj.getClass() == tclass is not removed.
Given that in for your test there is no subclass of AFUBench, it should work.
So my guess is that the type of 'this' inside the test is not propagated to the method 'get', am i right ?


----- Mail original -----
> De: "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
> À: "hotspot compiler" <hotspot-compiler-dev at openjdk.java.net>
> Envoyé: Lundi 26 Octobre 2015 15:14:30
> Objet: RFC (S) 8140483: Atomic*FieldUpdaters final fields should be trusted
> 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