Concurrency warning about dycon

[nnym]

Thanks for the tip. I had the false impression that the JVM prevented concurrent dynamic constant bootstrap and didn't think to check. I probably should remove the examples too then.

If you put those two things together, it adds up to potential deadlock if user locking is used and there is a cycle in constant initialization.

The quotation above seems to preclude deadlocks and I don't understand how they fit together to produce it. In any case, cycles in initialization seem like the responsibility of the programmer (just like endless cycles in function calls) to me.

[dmlloyd]

Thanks for the tip. I had the false impression that the JVM prevented concurrent dynamic constant bootstrap and didn't think to check. I probably should remove the examples too then.

It's unfortunate to be sure. With the recent talk of lazy statics, I wonder if they don't regret this decision now.

If you put those two things together, it adds up to potential deadlock if user locking is used and there is a cycle in constant initialization.

The quotation above seems to preclude deadlocks and I don't understand how they fit together to produce it.

They only do when combined with the latter part of the sentence "... if user locking is used". Sorry if my wording is not clear.

In any case, cycles in initialization seem like the responsibility of the programmer (just like endless cycles in function calls) to me.

Yes, this is a valid perspective. The user does have to be careful when using locks in combination with indeterminate initialization order; the JVM will do nothing to help you diagnose the issue if you do inadvertently cause a deadlock (which is unfortunate IMO).