Selectively Shifting and Constraining Computation

[John Rose]

On 24 Oct 2022, at 19:06, David Lloyd wrote:

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

In short, probably not.  You’d have lots of extra footprint (all those monitor states) for no demonstrable gain.  (…Despite the speculations you made, which I also made but w/o coming to any definite benefit.)  You’d lose something too:  The sequencing of initialization (lazy and not-lazy) of a single class would lose coherence.  This IMO is a risk:  The more lazies differ from not-lazies, the more possibility of bugs when adopting lazies.  And allowing a class to run initialization expressions concurrently is surely much less compatible with the current state, where initialization expressions are run in sequence.

So to me it was a no-brainer to use the existing lock “LC”.

> 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