RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v6]

[Ashutosh Mehra]

On Thu, 28 Aug 2025 21:17:42 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.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap
>  - @DanHeidinga comments -- added comments and asserts about the handling of enums
>  - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase
>  - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run
>  - @DanHeidinga comments
>  - tightened SystemDictionary::preload_class()
>  - Fixed bugs found in JCK
>  - added entry in ProblemList-AotJdk.txt due to 8323727
>  - more clean up
>  - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/075ddef8...1a8ea501

src/hotspot/share/cds/aotOopChecker.cpp line 53:

> 51: // the production run.
> 52: void AOTOopChecker::check(oop obj) {
> 53:   precond(vmClasses::URL_klass()->is_final());

`AOTOopChecker::check` is a generic method, so this precond should ideally be inside the next block that explicitly handles URL class objects.

src/hotspot/share/cds/aotOopChecker.cpp line 55:

> 53:   precond(vmClasses::URL_klass()->is_final());
> 54: 
> 55:   if (obj->klass()->is_subclass_of(vmClasses::URL_klass())) {

URL is a final class, so shouldn't `obj->klass() == vmClasses::URL_klass()` be sufficient?

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

> 1061: 
> 1062: // Statically allocate fixup lists because they always get created.
> 1063: void java_lang_Class::allocate_fixup_lists() {

Do we need `fixup_module_field_list` when `is_using_preloaded_classes` is true?

src/hotspot/share/memory/iterator.inline.hpp line 58:

> 56:     ClaimMetadataVisitingOopIterateClosure::do_cld(cld);
> 57:   } else {
> 58:     assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity");

Why is the null check and assert not valid anymore?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2331108015
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2334124611
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2334124798
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2334211674