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

[John Rose]

On Jan 11, 2020, at 3:59 AM, forax at univ-mlv.fr wrote:
> 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.

And even better than that is fixing “final” so it’s really final.

But @TrueScottmanFinal is surprisingly harder than @Stable.
The problem is that the JIT needs to distinguish two states
that look very similar:  1. The final variable is freshly created
and hasn’t been initialized yet, and 2. The final variable has
been initialized (redundantly) to its default value.

The design of @Stable neatly steps around this problem by
defining the contract to be the same in both cases.  A real
fix to “final”, or an intermediate @TrueScottmanFinal, seems
to require new mechanisms in the JVM for tracking initialization
(at least, initialization to default).  Either that or else we need
to convince ourselves that it’s OK for the JIT to capture the
default value from an uninitialized final and hold onto it
forever, which I don’t think works.  Or a hybrid scheme
where the JIT captures a default and polls for updates,
somehow, at some rate.  The problem with these latter
solutions is that (a) they probably will cause bugs, and (b)
they are probably (but not certainly) illegal in the JMM,
since the JMM does not clearly model the effects of threads
re-using JIT-ted code.

So, coming up from that deep dive, the result is that we
are stuck with @Stable for the present, not because it is
the perfect design for the job, but it is the best we can do
without adding complicated tracking to JIT constants.
It’s served us well, and will continue to do so until we do
that extra work.

— John