Selectively Shifting and Constraining Computation

[forax at univ-mlv.fr]

----- Original Message -----
> From: "John Rose" <john.r.rose at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "mark reinhold" <mark.reinhold at oracle.com>, "leyden-dev" <leyden-dev at openjdk.org>
> Sent: Tuesday, October 25, 2022 2:39:20 AM
> Subject: Re: Selectively Shifting and Constraining Computation

> 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.

I've just read it, i like it, it's far better than the previous semantics and using the same lock as <clinit> will allow IDEs to provide nice refactoring without having to think too much.

One question: should the new BSM protocol also work with indy BSM, it does has to given that condy update a the constant pool constant while indy update a method handle target, so not the same data structure in memory but it may be nice to use the same umbrella.

Also, it will not only benefit Java but also Clojure or any other languages on top of the JVM that use reified objects to represent its code.

Rémi