On Tue, 9 Sep 2025 16:46:13 GMT, Ashutosh Mehra <asme...@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
