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). Yes, thanks, that is what I liked to see. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/33173#pullrequestreview-5395209184
