Non-fatal assert in extended.functional with JITServer and AOT cache: Must have shared VM access

[cjjdespres]

The assert occurred with a debug build on JDK21 xlinux, with a manually-started JITServer on the side, with the client requesting the JITServer AOT cache be used, in the component MockitoMockTest_0 (the first component to be run in extended.functional, I believe). I still need to check whether or not this shows up without AOT cache or without JITServer entirely.

The assert is here:

https://github.com/eclipse-openj9/openj9/blob/e81a895c37ed86b70386aae57d93131a0736d29c/runtime/compiler/env/ClassLoaderTable.cpp#L192

From the core, jvmtiRetransformClasses was called, eventually getting to internalCreateRAMClassDone. That triggered jitHookClassLoadHelper, that called associateClassLoaderWithClass, at which point the assert fired. The class that was done being created was java/lang/Object.

I see where the change might have happened, actually. Here:

https://github.com/eclipse-openj9/openj9/blob/e81a895c37ed86b70386aae57d93131a0736d29c/runtime/jvmti/jvmtiClass.c#L1195-L1199

the safePoint variable should be non-zero (the J9_EXTENDED_RUNTIME_OSR_SAFE_POINT flag is set in vm->extendedRuntimeFlags), and the backtrace indicates we were at the recreateRAMClasses call just down from there. If you look at commit https://github.com/eclipse-openj9/openj9/commit/e83d9d1cf94666f0298f3057d24ed39b431dcf66, acquireSafePointVMAccess was changed so that the vm->exclusiveCount was set to 1 when acquiring safe point VM access, and this is how the code stands today. I don't know if that's a full explanation of why the assert is firing now - if we were ever not at a safePoint before that change, we'd acquire exclusive VM access and presumably trigger the same assert when running associateClassLoaderWithClass, but perhaps that code path is somehow impossible.

The assert was added in https://github.com/eclipse-openj9/openj9/pull/12154, but I couldn't see a discussion of why shared VM access was needed specifically here. Do you happen to remember why that was the case, @mpirvu?