On Fri, 2 Oct 2026 13:42:02 GMT, Frederic Parain <[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). > > src/java.base/share/classes/java/lang/runtime/ValueObjectMethods.java line 43: > >> 41: final class ValueObjectMethods { >> 42: private static final Unsafe UNSAFE = Unsafe.getUnsafe(); >> 43: private static final boolean VERBOSE = false; > > Now that the `VERBOSE` field is not configurable dynamically, should it > simply be removed from the source code? Changing its value for debugging > purposes would now require to change the source code and recompile anyway. So > the manual source modifications could include adding the debugging/logging > code too. I find these flags still useful, so I can flip it in _one place_ instead of changing a whole lot of code. So just putting this flag to default `false` is good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33173#discussion_r4167732504
