Lazy statics (was: Re: Selectively Shifting and Constraining Computation)

[Dan Heidinga]

John, nice write up on the Lazy static finals JEP.

Reading the JEP I was curious about one of the restrictions - the need for
the static field to be "final".  There's a clear transformation from the
IODH pattern to a static final field that's appealing and finals allow for
better optimization so it's an obvious first target.

The semantics in the JEP though seem like they would work equally well for
non-final static fields as well.  Users can already implement this
themselves today due to the mutability of the field, but I can see a
benefit to allowing users to specify a lazy initializer for mutable fields
as well.

Is extending it to all static fields (both final and non-final) a potential
follow on to this work?

--Dan

On Mon, Oct 24, 2022 at 8:39 PM John Rose <john.r.rose at oracle.com> wrote:

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20221114/58e172df/attachment.htm>