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

Ioi Lam has updated the pull request with a new target base due to a merge or a 
rebase. The pull request now contains 16 commits:

 - Merge branch 
'jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver' into 
jep-483-step-03-8329706-implement-xx-aot-class-linking
 - Merge branch 
'jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver' into 
jep-483-step-03-8329706-implement-xx-aot-class-linking
 - @dholmes-ora comments
 - @dholmes-ora comments
 - Fixed ZERO build
 - minor comment fix
 - @ashu-mehra comment: move code outside of call_initPhase2(); also renamed 
BOOT/BOOT2 to BOOT1/BOOT2 and refactored code related to AOTLinkedClassCategory
 - @ashu-mehra reviews
 - @ashu-mehra comments
 - @adinn comments
 - ... and 6 more: https://git.openjdk.org/jdk/compare/0859631f...3cdc7634

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

Changes: https://git.openjdk.org/jdk/pull/20843/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20843&range=12
  Stats: 1788 lines in 47 files changed: 1631 ins; 57 del; 100 mod
  Patch: https://git.openjdk.org/jdk/pull/20843.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20843/head:pull/20843

PR: https://git.openjdk.org/jdk/pull/20843

Reply via email to