On Tue, 3 Sep 2024 20:57:48 GMT, Ioi Lam <[email protected]> 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
> exact same set of modules are visible whe...
src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 86:
> 84:
> 85: load_table(AOTLinkedClassTable::for_static_archive(), loader_kind,
> h_loader, current);
> 86: assert(!current->has_pending_exception(), "VM should have exited due to
> ExceptionMark");
An `ExceptionMark` only triggers a VM exit on construction and destruction, if
an exception is pending.
src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 143:
> 141: InstanceKlass* ik = classes->at(i);
> 142: if (log_is_enabled(Info, cds, aot, load)) {
> 143: ResourceMark rm;
Suggestion:
ResourceMark rm(THREAD);
src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 162:
> 160:
> 161: if (actual != ik) {
> 162: ResourceMark rm;
Suggestion:
ResourceMark rm(THREAD);
src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 196:
> 194: if (ik->is_public() && !ik->is_hidden()) {
> 195: if (log_is_enabled(Info, cds, aot, load)) {
> 196: ResourceMark rm;
Suggestion:
ResourceMark rm(current);
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20843#discussion_r1746512974
PR Review Comment: https://git.openjdk.org/jdk/pull/20843#discussion_r1746513849
PR Review Comment: https://git.openjdk.org/jdk/pull/20843#discussion_r1746514062
PR Review Comment: https://git.openjdk.org/jdk/pull/20843#discussion_r1746514572
