Selectively Shifting and Constraining Computation

[John Rose]

On 21 Oct 2022, at 22:56, forax at univ-mlv.fr wrote:

> I'm a great fan of the lazy statics, but you do not only get reordering of the side effects, you may also get double executions of the initialization code, double executions of the side effects.
> So the constraint on the side effects when initializing a lazy static is quite radical, do not do them .

I think you are referring to the draft semantics of lazies which piggy-back on top of CONSTANT_Dynamic, which indeed allows initialization races and therefore double side effects.  I’m getting rid of this in the newest draft of the JEP, so that refactoring to lazy will be easier to say “yes” to.

A lazy static should never double its initializer, regardless of init-races.  My current plan is to insist that the same class locking be done for each lazy init as for <clinit> itself (which is the big lazy init of the overall class).  And on the same CL object mentioned in JVMS 5.5.

Also, errors in lazy inits will be recorded as ExceptionInInitializerError, not BootstrapMethodError.  Both effects require some subtle tweaking of the bootstrapping of lazies, which I’m working on…

I just updated the JEP to reflect this:  https://bugs.openjdk.org/browse/JDK-8209964

There’s a new section on translation strategy.  It hints at adjustments to the BSM protocol, which I’m currently investigating.  The basic idea there is that a BSM can ask that the JVM pass it exactly one argument, which reifies the entire state of the relevant condy entry, and allows the BSM to update that state appropriately as it arbitrates error and race conditions.

See also a slide deck mentioned in the comments.