On Fri, 2 Oct 2026 13:18:36 GMT, Dan Heidinga <[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). > > This looks good! Thanks Thanks for the reviews @DanHeidinga , @fparain and @shipilev . I'm looking into the `post_early_vm_start` issue that Aleksey raised. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33173#issuecomment-6007604440
