RFR: 8338379: Accesses to class init state should be properly synchronized [v2]

[Aleksey Shipilev]

On Fri, 27 Sep 2024 16:14:29 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I really wonder about the acquire barrier in `LIR_Assembler::emit_alloc_obj`. The interesting fields of the class are already read by `LIRGenerator::new_instance` during compile time. How can an acquire barrier after the execution help? At least, it doesn't help the allocation itself.

Well, that's the thing: if compiler _does not know_ the class is initialized, it emits the runtime check for class initialization. Here, in `LIRGenerator::new_instance` we enter with `init_check = true` (`!klass->is_initialized()`):
https://github.com/openjdk/jdk/blob/65200a9589e46956a2194b20c4c90d003351a539/src/hotspot/share/c1/c1_LIRGenerator.cpp#L670-L671

In generated code, we come to `init_check` block, check at runtime if class is fully initialized, and proceed to the rest of allocation path if so:

https://github.com/openjdk/jdk/blob/f554c3ffce7599fdb535b03db4a6ea96870b3c2d/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp#L2275-L2277

If we were the only thread, it would not have been a problem: on first entry we would have called the stub, initialized the class and completed the allocation there. Next time around we would have passed `init_check == fully_initialized`, and proceeded without calling a stub.

But the caveat we are handling in this PR is that if _some other thread_ might have completed the class initialization, we need to make sure _this thread_ sees the class state consistently. For example, if its Java constructor reads class statics written in `<clinit>`. The initializing thread would do release-store for `init_check = fully_initialized`. On this reader side, we need a related acquire-load in the runtime check. Since runtime check does not run often -- most of the time compilers know the class is definitely initialized, the change does not affect performance all that much, if at all.

Makes sense?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21110#issuecomment-2379809426