JDK-8343023 : [premain] AOT cache cleanup umbrella/wishlist
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2024-10-24
  • Updated: 2025-03-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
Relates :  
Relates :  
Description
Here a list of RFEs and BUGs related to making HotSpot AOT logic more maintainable, robust, understandable, or evolvable.

Leave a comment on this RFE if you think you see a problem in the sources, but your idea about how to fix it is not specific enough for an RFE.  We'll generate the RFEs together.

General areas of work:

 - decoupling the VM from AOT design, moving AOT logic into Java code
 - removing limitations (or, clarifying limitations)
 - improving toolability, transparency, configurability
 - replacing temporary tactics that have not aged well
 - separating or refactoring AOT logic relative to normal (JIT) HotSpot logic

Specific work items (this list will change over time):

- contract adjustments for stable, and usage corrections
- Mat C.’s hook for ending training runs (small API upgrade)
- fix for handling signed JARs (minor bug in PIT)
- fix for class loader table overflow (minor bug in PIT)
- cleanups for bootstrap orchestration (this is open-ended)
- clarify user model for integer box cache, when using AOT cache
- get rid of the “scratch object” lifecycle in AOT processing
- simplify Java heap walk during assembly phase (Ioi has ideas on this)
- make SoftReference safe to use in the assembly phase
- add more VM checks to exclude surprises in initialization order during boot-up
- maybe also annotation driven design rule checks in the VM (no-AOT, must-AOT, etc.)
- add more logging options to extract info from TR or AP
- add some "VM oracle" commands to modify AP activities
- make a simplified one-step workflow that creates the AOT cache directly from the TR
- do performance tuning (e.g., pretouch pages during boot-up)

Comments
I plan to fix this soon after JEP 483 integration: JDK-8344140 Consolidate AOT cache logic for artifact gathering
13-11-2024

[~jrose] I filed https://bugs.openjdk.org/browse/JDK-8343019 for the boxed Integer cache issue. Is it a good idea to link it into this umbrella/wishlist bug? Thanks
24-10-2024

Please clarify the user model for the integer box cache configuration. Best consensus so far: The user can specify the size of the IBC when generating an AOT cache. That is recorded in the AOT cache and becomes the default size in production. An attempt to change it in production should produce a warning. The VM may drop the AOT cache if it cannot satisfy the new requirement. This may eventually impact users who are surprised that the built-in AOT cache (when we use the new tech. for the built-in cache) will complain if they use their old workflow of setting the box cache configuration at production startup (they didn't know about the training run).
24-10-2024

One tactic which hasn't aged well: "scratch classes" (also "scratch RR arrays"). We should embrace the principle that the assembly phase is building ready-to-use structures, which are dumped as AOT assets, and then adopted more or less immediately into the running VM. An example anti-pattern to this is having two mirror objects at one time for one class (regular plus scratch mirror). We should edit the "real" mirror (and real RR array) to remove undumpable data. That would mean zeroing static fields of the mirror of any class which is not AOT-initialized.
24-10-2024