RFR: 8350550: Preload classes from AOT cache during VM bootstrap

[Dan Heidinga]

On Thu, 17 Jul 2025 22:38:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. 
> 
> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`.
> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved.
> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java.

src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 96:

> 94:   // later in load_javabase_classes() and load_non_javabase_classes().
> 95:   preload_classes_in_table(AOTLinkedClassTable::for_static_archive()->boot1(), "boot1", Handle(), CHECK);
> 96:   preload_classes_in_table(AOTLinkedClassTable::for_static_archive()->boot2(), "boot2", Handle(), CHECK);

why do we maintain both a `boot1` and `boot2` set here when both are loaded before executing any Java code?  Is the distinction meaningful for preloaded classes given both are loaded into the same classloader?

src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 127:

> 125:           precond(ik->local_interfaces()->at(i)->is_loaded());
> 126:         }
> 127:       });

This debugging check is duplicated in `SystemDictionary::preload_class` in the `#ifdef ASSERT` block.

src/hotspot/share/cds/cdsHeapVerifier.cpp line 241:

> 239:           }
> 240:           if (field_ik == vmClasses::Boolean_klass()) {
> 241:             // TODO: check if is TRUE or FALSE

Are we canonicalizing Boolean.TRUE & Boolean.FALSE and thus don't care if a static field points to them?  And Boolean.TYPE isn't getting the same treatment?

src/hotspot/share/classfile/javaClasses.cpp line 1017:

> 1015: void java_lang_Class::set_mirror_module_field(JavaThread* current, Klass* k, Handle mirror, Handle module) {
> 1016:   if (CDSConfig::is_using_preloaded_classes()) {
> 1017:     oop archived_module = java_lang_Class:: module(mirror());

Suggestion:

    oop archived_module = java_lang_Class::module(mirror());

src/java.base/share/classes/java/net/URL.java line 1768:

> 1766: 
> 1767:     @AOTRuntimeSetup
> 1768:     private static void runtimeSetup() {

Slightly concerned with this for reasons I'm still trying to track down - Mostly around the `URLStreamHandler` that each URL instance holds onto.

Can we create cases were the cached URLStreamHandler for a URL from the assembly phase would be different than the URLStreamHandler looked up in the production run?

src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 407:

> 405:     static class Holder {
> 406:         // All native libraries we've loaded.
> 407:         private static final Set<String> loadedLibraryNames =

I'm concerned about this causing problems if we ever AOT initialize a user class that calls `System.loadLibrary` from its static initializer.

Should we add a check to the `clear()` method above to ensure that only the expected libraries have been loaded during the assembly phase?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2283111220
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2283328974
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2283162998
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2283173361
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2283406179
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2291474398