Concurrency warning

[dmlloyd]

Note that dynamic constants do not have exclusive initialization like classes do (to draw a parallel to the lazy-holder pattern example). This means that each time a thread encounters an uninitialized dynamic constant, the bootstrap for it is invoked from that thread, which in turn means that the bootstrap may be concurrently invoked. This is especially significant if the initialization is expensive. In this case, the user would need to introduce their own locking strategy.

For more information, see section 5.4.3.6 of the JVM specification, particularly this passage at the bottom of the section:

If several threads attempt resolution of R at the same time, the bootstrap method may be invoked concurrently. Therefore, bootstrap methods which access global application data must take precautions against race conditions.

Also of interest in that section is:

Unlike class initialization (§5.5), where cycles are allowed between uninitialized classes, resolution does not allow cycles in symbolic references to dynamically-computed constants. If an implementation of resolution makes recursive use of a stack, then a StackOverflowError will occur naturally. If not, the implementation is required to detect the cycle rather than, say, looping infinitely or returning a default value for the dynamically-computed constant.

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 documentation should probably be updated to reflect this.

[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).