Selectively Shifting and Constraining Computation

[forax at univ-mlv.fr]

> From: "John Rose" <john.r.rose at oracle.com>
> To: "mark reinhold" <mark.reinhold at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "leyden-dev" <leyden-dev at openjdk.org>
> Sent: Tuesday, October 18, 2022 8:18:08 PM
> Subject: Re: Selectively Shifting and Constraining Computation

> And backing out of those particular points raised by Remi, I’d like to say that
> this was a good read; thanks Mark.

> Time-shifting is IMO a deeply fruitful notion, and will probably carry beyond
> the specific use cases of adjusting class loading order and static-final
> constant values. I hope we can find a few tiny spots in the language and VM
> specs where we can remove unimportant restrictions that will make various forms
> of time-shifting (forward and backward, global and local) semantically neutral,
> with respect to specified semantics. To do that we will have to make some parts
> of the specification more lenient towards reordering of expressions that might
> have side effects, and/or some way to constrain side effects. But we must do so
> with exquisite care, and (often) with opt-in from the user. That’s how lazy
> statics are conceived currently: They can be reordered because they are
> uncoupled from their class’s <clinit> , and the uncoupling must be explicitly
> permitted by the user. It’s a very interesting problem, and a very worth-while
> one.

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 like the way you link time-shifting to the introduction of constraints. I
> already mentioned how the idea of constraints might tie to call sites. Maybe
> also data structure fields; who knows. I’m not in a hurry to figure it all out;
> it feels like we are at the start of some years of excellent investigation.

> — John

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20221022/bce86294/attachment.htm>