On Jan 11, 2020, at 3:59 AM, fo...@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
