On Fri, 2 Oct 2026 02:22:19 GMT, David Holmes <[email protected]> wrote:
> As per JBS the `JNIHandles::is_same_object` method was not ensuring the > `ValueObjectMethods` class was initialized before invoking its method. Rather > than add another on-demand initialization of this class it was decided to > treat this like many other well-known and well-used classes and initialize it > early in the VM init sequence. This required removing some debugging code > from the VOM class as it was dependent on a System Property which meant the > initialization could not happen until during `initPhase1()` after system > properties and charset et al are initialized. It was realized that this meant > there would be a large number of core classes that would be unable to utilise > value objects within their initialization actions, now and in the future, and > so we removed this limitation and moved the initialization as soon as > possible - which is after `UnsafeConstants` has been initialized. > > The remaining changes then removed the unnecessary explicit initialization, > and also standardised the upcall related code to use > `Universe::is_substitutable_method()` (which asserts that the class has been > initialized so we can detect too-early value object usage). As we know the > class is initialized, and we have already resolved the method, we can use the > direct `JavaCalls::call()` invocation instead of the `call_static` that > performs resolution. > > Testing: > - all valhalla tests locally > - tiers 1-3 (sanity) > - tier7 enable-preview subset > > Thanks > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). Hold on a second, I think there is a bootstrapping gap: `JvmtiExport::post_early_vm_start` runs before UnsafeConstants/VOM init. So if that agent ends up calling `IsSameObject` through JNI, we get to uninitialized VOM and things break. The pre-PR code crashed, AFAICS, when trying to access System properties during VOM init, now it (silently?) passes? Should we turn some assert to guarantee to make sure we still crash in release when this corner case happens? ------------- PR Comment: https://git.openjdk.org/jdk/pull/33173#issuecomment-5990556527
