P3
An AOT cache contains various types of pre-computed artifacts for a set of Java classes. E.g.,
- The C++ and Java representation of the Java classes and their bytecodes. E.g., InstanceKlass in C++ or java.lang.invoke.MethodHandle in Java.
- Java heap objects (instances of Java classes)
- AOT execution profile (upcoming in JDK-8325147)
- AOT compiled Java methods (upcoming in JDK-8335368)
For these artifacts to be valid, the corresponding Java classes (InstanceKlasses) must be already in at least the loaded state in the HotSpot SystemDictionary. In addition, some artifacts require their corresponding Java classes to be in the linked state.
In JDK 24, the set of classes managed by aotLinkedClassBulkLoader.cpp are programmatically loaded, in 4 different stages, into the system dictionary
- classes in java.base
- boot loader classes in other packages
- platform loader classes
- app loader classes
During the loading of these classes, Java methods may be executed (e.g., to initialize ProtectionDomain objects). This already requires a workaround in [1] to allow object instances of not-yet-loaded classes. When we add AOT compiled Java methods, we would need to introduce extra checks to avoid executing code of classes not yet loaded. Such checks complicates the GC and compiler subsystems, and slows down VM start-up.
==========
Proposal
- During VM bootstrap, make sure that all InstanceKlasses used by AOT artifacts are in the required "loaded" or "linked" state BEFORE executing any Java code, or BEFORE any GC is executed.
- Create all Java objects related to the loaded classes (ProtectionDomain, CodeSource, Package, etc) during the AOT cache assembly phase.
- Finish class linking (Java itable/vtables computation) during the AOT cache assembly phase.
- Pre-compute the system dictionary during the AOT cache assembly phase.
This RFE will be implemented in multiple steps (as subtasks -- to be filed).
==========
[1] https://github.com/openjdk/jdk/blame/302bed055c3b4881f97c584d5953273b9dbc2969/src/hotspot/share/memory/iterator.inline.hpp#L53-L60
- The C++ and Java representation of the Java classes and their bytecodes. E.g., InstanceKlass in C++ or java.lang.invoke.MethodHandle in Java.
- Java heap objects (instances of Java classes)
- AOT execution profile (upcoming in JDK-8325147)
- AOT compiled Java methods (upcoming in JDK-8335368)
For these artifacts to be valid, the corresponding Java classes (InstanceKlasses) must be already in at least the loaded state in the HotSpot SystemDictionary. In addition, some artifacts require their corresponding Java classes to be in the linked state.
In JDK 24, the set of classes managed by aotLinkedClassBulkLoader.cpp are programmatically loaded, in 4 different stages, into the system dictionary
- classes in java.base
- boot loader classes in other packages
- platform loader classes
- app loader classes
During the loading of these classes, Java methods may be executed (e.g., to initialize ProtectionDomain objects). This already requires a workaround in [1] to allow object instances of not-yet-loaded classes. When we add AOT compiled Java methods, we would need to introduce extra checks to avoid executing code of classes not yet loaded. Such checks complicates the GC and compiler subsystems, and slows down VM start-up.
==========
Proposal
- During VM bootstrap, make sure that all InstanceKlasses used by AOT artifacts are in the required "loaded" or "linked" state BEFORE executing any Java code, or BEFORE any GC is executed.
- Create all Java objects related to the loaded classes (ProtectionDomain, CodeSource, Package, etc) during the AOT cache assembly phase.
- Finish class linking (Java itable/vtables computation) during the AOT cache assembly phase.
- Pre-compute the system dictionary during the AOT cache assembly phase.
This RFE will be implemented in multiple steps (as subtasks -- to be filed).
==========
[1] https://github.com/openjdk/jdk/blame/302bed055c3b4881f97c584d5953273b9dbc2969/src/hotspot/share/memory/iterator.inline.hpp#L53-L60