On 2020-01-11 12:59, fo...@univ-mlv.fr wrote:
------------------------------------------------------------------------
*De: *"John Rose" <john.r.r...@oracle.com>
*À: *"Remi Forax" <fo...@univ-mlv.fr>
*Cc: *"Claes Redestad" <claes.redes...@oracle.com>, "core-libs-dev"
<core-libs-dev@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 <fo...@univ-mlv.fr
<mailto:fo...@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
