RFR: 8236850: Operations on constant List/Set.of(element) instances does not consistently constant fold

[Claes Redestad]

On 2020-01-11 12:59, forax at univ-mlv.fr wrote:
> 
> 
> ------------------------------------------------------------------------
> 
>     *De: *"John Rose" <john.r.rose at oracle.com>
>     *À: *"Remi Forax" <forax at univ-mlv.fr>
>     *Cc: *"Claes Redestad" <claes.redestad at oracle.com>, "core-libs-dev"
>     <core-libs-dev at openjdk.java.net>
>     *Envoyé: *Samedi 11 Janvier 2020 02:23:50
>     *Objet: *Re: RFR: 8236850: Operations on constant
>     List/Set.of(element) instances does not consistently constant fold
> 
>     On Jan 10, 2020, at 10:47 AM, Remi Forax <forax at univ-mlv.fr
>     <mailto:forax at univ-mlv.fr>> wrote:
> 
>         Seem to be a JIT bug to me,
>         the fields of Set12 are declared final not @Stable (even if the
>         field storing the instanceof of Set&2 itself is marked @Stable)
>         so there is no reason not not let the constant folding happen.
> 
> 
>     It’s part of the contract of @Stable that default values (null) are not
>     inlined.  The reason for this is that some @Stable variables are lazy,
>     and the JIT needs to avoid assuming that default values stay that
>     way forever.
> 
> 
> My bad, reading the patch i've not seen that the fields were both 
> annotated with final *and* @Shared.
> 
> So it's another occurrence of final not meaning true final but instead 
> of having an annotation @TrueScottmanFinal,
> this patch try to use @Stable but it doesn't work if the field is null, 
> so the code is twisted to consider 'this' as a marker for null.

Interestingly, -XX:+UnlockExperimentalVMOptions
-XX:+TrustFinalNonStaticFields does not help here: It seems null
"constants" are treated specially even in this case.

> 
> In my opinion, it's better to introduce an annotation @TrueScottmanFinal 
> instead of using @Stable in a way it was not designed to be used.

While something explicit like this is probably better, I don't think we
should hold back improvements in the short term, even hacky ones like
this. Especially when backing out the hack would be trivial once a
better way of doing things is invented (and the cost of forgetting about
it is low or non-existent).

/Claes