<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">On Mon, Oct 24, 2022 at 7:39 PM John Rose <<a href="mailto:john.r.rose@oracle.com">john.r.rose@oracle.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 21 Oct 2022, at 22:56, <a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a> wrote:<br>
<br>
> 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.<br>
> So the constraint on the side effects when initializing a lazy static is quite radical, do not do them .<br>
<br>
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.<br>
<br>
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.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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).</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>