RFR: 8288064: Class initialization locking

[Coleen Phillimore]

On Tue, 14 Jun 2022 23:18:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Use a native JVM monitor and state for mutual exclusion for class linking and initialization.  See CR for more details.
>> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on linux-x64-debug.  There isn't any platform dependent code in this change.
>
> src/hotspot/share/oops/cpCache.cpp line 269:
> 
>> 267:     if (invoke_code == Bytecodes::_invokestatic) {
>> 268:       assert(method->method_holder()->is_initialized() ||
>> 269:              method->method_holder()->is_reentrant(Thread::current()),
> 
> Please change this back - `is_reentrant` has no meaning by itself, reentrant with respect to what?

I can have a is_reentrant_initialization() and an is_reentrant_linking() method if that makes it clearer.

> src/hotspot/share/oops/instanceKlass.cpp line 1179:
> 
>> 1177: 
>> 1178:   // Now flush all code that assume the class is not linked.
>> 1179:   // Set state under the Compile_lock also.
> 
> Wow! Why do we have to do this now?

It's not new, it was moved.

> src/hotspot/share/runtime/vframe.cpp line 231:
> 
>> 229:     else if (thread()->osthread()->get_state() == CONDVAR_WAIT) {
>> 230:       // We are waiting on an Object monitor but Object.wait() isn't the
>> 231:       // top-frame, so we should be waiting on a Class initialization monitor.
> 
> Comment needs updating. I'm glad to see this still works okay with such a simple change.

Oh, yes, it does need updating.

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

PR: https://git.openjdk.org/jdk/pull/9141