Selectively Shifting and Constraining Computation

[David Lloyd]

On Mon, Oct 24, 2022 at 7: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.
>

Wouldn't it be preferable to use a lock per lazy static? One of the main
downsides of a static final field, apart from the lack of initialization
granularity, is how the initialization granularity interacts with the
corresponding lock granularity. So if I naively have fields that seem
"constant" with only "constant" dependencies (in the form of other static
final fields), and those classes may be initialized by multiple threads in
an indeterminate order, I may introduce a deadlock. It would be unfortunate
if lazy statics were prone to the same kind of deadlock due to the coarse
granularity that I would assume would have been left behind.

By having a lock per field, I believe it would be significantly less likely
to introduce a deadlock inadvertently (maybe even impossible if
initialization cycles could be detected somehow, but it's late here and
maybe my tired brain didn't reason this correctly).

-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20221024/b9881db3/attachment.htm>