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

Ioi Lam iklam at openjdk.org
Wed Sep 10 04:16:07 UTC 2025


On Mon, 8 Sep 2025 18:57:16 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 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.

I moved this line inside the next block. I also added comments that in the future we may check more types of 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?

Since the `precond` is now inside this block, I can't use `==` anymore. Othewise if we had an instance of a subclass of URL then we will never get into the `if` block.

> 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?

I've added comments why fixup_module_field_list is not needed when is_using_preloaded_classes is true?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499266
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499303
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499362


More information about the core-libs-dev mailing list