On Fri, 6 Sep 2024 05:10:42 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> This is the 3rd PR for [JEP 483: Ahead-of-Time Class Loading & >> Linking](https://bugs.openjdk.org/browse/JDK-8315737). >> >> **Overview** >> >> - A new `-XX:+AOTClassLinking` flag is added. See [JEP >> 498](https://bugs.openjdk.org/browse/JDK-8315737) and the >> [CSR](https://bugs.openjdk.org/browse/JDK-8339506) for a discussion of this >> command-line option, its default value, and its impact on compatibility. >> - When this flag is enabled during the creation of an AOT cache (aka CDS >> archive), an `AOTLinkedClassTable` is added to the cache to include all >> classes that are AOT-linked. For this PR, only classes for the >> boot/platform/application loaders are eligible. The main logic is in >> `aotClassLinker.cpp`. >> - When an AOT archive is loaded in a production run, all classes in the >> `AOTLinkedClassTable` are loaded into their respective class loaders at the >> earliest opportunity. The main logic is in `aotLinkedClassBulkLoader.cpp`. >> - The boot classes are loaded as part of `vmClasses::resolve_all()` >> - The platform/application classes are loaded after the module graph is >> restored (see changes in `threads.cpp`). >> - Since all classes in a `AOTLinkedClassTable` are loaded before any >> user-code is executed, we can resolve constant pool entries that refer to >> these classes during AOT cache creation. See changes in >> `AOTConstantPoolResolver::is_class_resolution_deterministic()`. >> >> **All-or-nothing Loading** >> >> - Because AOT-linked classes can refer to each other, using direct C++ >> pointers, all AOT-linked classes must be loaded together. Otherwise we will >> have dangling C++ pointers in the class metadata structures. >> - During a production run, we check during VM start-up for incompatible VM >> options that would prevent some of the AOT-linked classes from being loaded. >> For example: >> - If the VM is started with an JVMTI agent that has ClassFileLoadHook >> capabilities, it could replace some of the AOT-linked classes with >> alternative versions. >> - If the VM is started with certain module options, such as >> `--patch-module` or `--module`, some AOT-linked classes may be replaced with >> patched versions, or may become invisible and cannot be loaded into the JVM. >> - When incompatible VM options are detected, the JVM will refuse to load an >> AOT cache that has AOT-linked classes. See >> `FileMapInfo::validate_aot_class_linking()`. >> - For simplfication, `FileMapInfo::validate_aot_class_linking()` requires >> `CDSConfig::is_using_full_module_graph()` to be true. This means that the >> exa... > > src/hotspot/share/cds/archiveUtils.cpp line 390: > >> 388: return "boot"; // boot classes in java.base >> 389: } else { >> 390: return "boot2"; // boot classes outside of java.base > > Suggestion: boot -> boot-base, boot2 -> boot-nonbase ? I prefer boot/boot2 to make the output easier to read. Anyone debugging this output will need to read the code to understand what "boot2" or "boot-nonbase" is. A few extra characters here will not help. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20843#discussion_r1747824950
