RFR: 8329706: Implement -XX:+AOTClassLinking

Ioi Lam iklam at openjdk.org
Wed Sep 4 22:07:30 UTC 2024


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 when the AOT cache was created, and when the AOT cache is used. 

**Testing**

- New test cases are added to test specific behaviors of the `-XX:+AOTClassLinking` flag
- A new test group `hotspot_aot_classlinking` is created for running existing CDS tests with the `-XX:+AOTClassLinking` flag. Note that this group filters out test cases that are incompatible with `-XX:+AOTClassLinking`. E.g., classes that use JVMTI ClassFileLoadHook or class redefinition.
- We will also modify some of our internal test cases (e.g., with large applications) to also run with the `-XX:+AOTClassLinking` flag.

---
See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

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

Depends on: https://git.openjdk.org/jdk/pull/20517

Commit messages:
 - More clean up
 - 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
 - 8329706: Implement -XX:+AOTClassLinking

Changes: https://git.openjdk.org/jdk/pull/20843/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20843&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329706
  Stats: 1734 lines in 46 files changed: 1577 ins; 52 del; 105 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


More information about the serviceability-dev mailing list