RFR: 8369742 link aot linked classes at vm bootstrap

[Ioi Lam]

On Tue, 14 Oct 2025 17:26:29 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> **PROBLEM**
>> 
>> If we have an AOT-initialized class like this in java.base
>> 
>> 
>> @AOTSafeClassInitializer
>> class Foo {
>>     static Bar b = new Bar(); // AOT-cached
>>     static void doit() {
>>         b.toString(); /// invokevirtual Bar::toString()Ljava/lang/String;
>>     }
>> }
>> 
>> 
>> If `Foo.doit()` is called before `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, it's possible for the `Bar` class to be not yet linked. The `invokevirtual` bytecode will crash because the vtable of the object `b` is not yet initialized.
>> 
>> **FIX**
>> 
>> Before we execute the first Java bytecode, unconditionally link all AOT-linked classes. This will ensure that the `Bar` class will have an initialized vtable for the above example.
>> 
>> **NOTES**
>> 
>> - The scenario in the  above example does not affect JDK 24, 25 or the current JDK mainline (26). We are lucky that in all the bytecode execution up to `AOTLinkedClassBulkLoader::link_or_init_javabase_classe()`, whenever we do a vtable/itable dispatch on an AOT-cached heap object, we happen to have already linked its class (either by explicit calls from the JVM, or as side effect of invokestatic/getstatic/putstatic/new). However, this is a potential problem that should be fixed. I have run into this problem when implementing [JDK-8368199](https://bugs.openjdk.org/browse/JDK-8368199), which changes the bytecodes that are executed in early VM bootstrap.
>> - I had to enable `CDSConfig::is_preserving_verification_constraints()` to for the static CDS archive. The reason is to avoid class loading. Please see the new comments in `AOTLinkedClassBulkLoader::link_classes_in_table()`.
>> - The change in `AdapterHandlerLibrary::create_native_wrapper` is for supporting JVMTI. The offending methods are `jdk.internal.vm.Continuation::enterSpecial` and `jdk.internal.vm.Continuation::doYield`. These are "continuation native intrinsic" methods that are usually linked much later after the ServiceThread have been started.
>
> src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 61:
> 
>> 59: //
>> 60: // Note: we can't link the classes yet because SharedRuntime is not yet ready to generate adapters.
>> 61: void AOTLinkedClassBulkLoader::preload_classes(JavaThread* current) {
> 
> Why we not ready for adapters? I see `SharedRuntime::init_adapter_library()` is called in from `init_globals()` and `preload_classes()` is called from `init_globals2()` when `universe2_init()` is called.
> 
> `SharedRuntime::init_adapter_library()` should populate table with AOT adapters.

The current call sequence is:

- SharedRuntime::init_adapter_library()
- AOTLinkedClassBulkLoader::preload_classes()
- MethodHandles::generate_adapters()
- AOTLinkedClassBulkLoader::link_classes()

Method linking calls `Interpreter::entry_for_method()` which looks up from `AbstractInterpreter::_entry_table`. However, this table is not yet initialized when `AOTLinkedClassBulkLoader::preload_classes()` is called. It's initialized inside `MethodHandles::generate_adapters()` which happens much later.

This table doesn't seem to be initialized by `SharedRuntime::init_adapter_library()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27783#discussion_r2430266856