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

[Ioi Lam]

On Tue, 9 Sep 2025 16:46:13 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>> 
>>  - @ashu-mehra review comments
>>  - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap
>>  - 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
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/8cd4e7d8...959a2c91
>
> 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?

The AOT cache can have heap objects whose class are loaded by the platform/app loaders. These objects usually come from aot-linked Lambda expressions.

Before this PR, the platform/app classes are loaded after executing quite a bit of Java code (i.e.,module graph initialization). It's possible for a GC to happen and discover those heap objects, whose classes are not yet loaded (i.e., having a null `cld`).

After this PR, all boot/platform/app classes are loaded before GC can happen, so we will never run into such null `cld` anymore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499472