AOT code JEP text updated
I have updated the text for the AOT code JEP: https://openjdk.org/jeps/8335368 I would appreciate any editorial comments. My present goal is to come closer to the style of our previous JEPs, and also to reflect recent conversations about AOT code. (That style is relatively non-technical and light on details, FTR. This is just the way things are with JEPs.) The recent conversations involve discussions about different AOT code shapes (AP4 vs. A4) and concerns about ISA compatibility. Please remind me of other recent conversations that may also be applicable to this JEP. Thanks! — John P.S. This is not urgent. I don’t think this JEP will be in the current release. But it is important!
Thank you, John, for working on it.
This will greatly reduce the initial load on the JIT compiler, reducing its interference with the application, in configurations with fewer cores.
May be: "reducing its interference with the application during startup, particularly in configurations with fewer cores." --- I agree that `(Delete this digression?)` should be removed. It describes how JIT compiler works. May be put it into wiki when you have time: https://wiki.openjdk.org/display/HotSpot/Compiler ---- Description
Even when peak performance requires additional JIT activity (to generate T4 code),
T4 is unknown. May be "new optimized code"?
(If you run a typical Java application with the option -XX:+PrintCompilation, and search for the string “made not entrant”, you will see many instances of the JIT replacing methods.)
It is too specific for this JEP. I don't think we need it. May be also mention that we record execution environment during training run (CPU's features, VM's flags) and compare them with environment during production run and completely discard AOT code if they don't match. --- AOT code implementation details I think it should be moved to Implementation RFE. It is too technical for JEP.
The AOT code tier A3 works the same as the JIT tier T3: It runs at a low optimization level, but collects the same kind of profile information that the VM interpreter gathers.
We don't cache T3. ---- Alternatives
Since AOT code can be loaded immediately on startup, it might seem that profiles in the AOT cache (added by JEP 515) are now useless. But they still have their role, when AOT code is replaced by the JIT.
As you mention in previous text, profiles trigger AOT code (A4) loading when all referenced in code classes are initialized. So you can't say that AOT profiles are useless for AOT code. Thanks, Vladimir K On 9/29/25 7:18 PM, John Rose wrote:
I have updated the text for the AOT code JEP:
https://openjdk.org/jeps/8335368
I would appreciate any editorial comments.
My present goal is to come closer to the style of our previous JEPs, and also to reflect recent conversations about AOT code.
(That style is relatively non-technical and light on details, FTR. This is just the way things are with JEPs.)
The recent conversations involve discussions about different AOT code shapes (AP4 vs. A4) and concerns about ISA compatibility. Please remind me of other recent conversations that may also be applicable to this JEP.
Thanks!
— John
P.S. This is not urgent. I don’t think this JEP will be in the current release. But it is important!
Thanks Vladimir. I have incorporated all of your suggestions. It’s much punchier, except for the Alternatives section. https://openjdk.org/jeps/8335368 On Oct 7, 2025, at 9:50 AM, Vladimir Kozlov <vladimir.kozlov@oracle.com> wrote: Thank you, John, for working on it.
This will greatly reduce the initial load on the JIT compiler, reducing its interference with the application, in configurations with fewer cores.
May be: "reducing its interference with the application during startup, particularly in configurations with fewer cores." --- I agree that `(Delete this digression?)` should be removed. It describes how JIT compiler works. May be put it into wiki when you have time: https://wiki.openjdk.org/display/HotSpot/Compiler ---- Description
Even when peak performance requires additional JIT activity (to generate T4 code),
T4 is unknown. May be "new optimized code"?
(If you run a typical Java application with the option -XX:+PrintCompilation, and search for the string “made not entrant”, you will see many instances of the JIT replacing methods.)
It is too specific for this JEP. I don't think we need it. May be also mention that we record execution environment during training run (CPU's features, VM's flags) and compare them with environment during production run and completely discard AOT code if they don't match. --- AOT code implementation details I think it should be moved to Implementation RFE. It is too technical for JEP.
The AOT code tier A3 works the same as the JIT tier T3: It runs at a low optimization level, but collects the same kind of profile information that the VM interpreter gathers.
We don't cache T3. ---- Alternatives
Since AOT code can be loaded immediately on startup, it might seem that profiles in the AOT cache (added by JEP 515) are now useless. But they still have their role, when AOT code is replaced by the JIT.
As you mention in previous text, profiles trigger AOT code (A4) loading when all referenced in code classes are initialized. So you can't say that AOT profiles are useless for AOT code. Thanks, Vladimir K
Thank you, John The text looks very good now for me. Vladimir K On 10/9/25 12:57 PM, John Rose wrote:
Thanks Vladimir. I have incorporated all of your suggestions. It’s much punchier, except for the Alternatives section.
https://openjdk.org/jeps/8335368
On Oct 7, 2025, at 9:50 AM, Vladimir Kozlov <vladimir.kozlov@oracle.com> wrote:
Thank you, John, for working on it.
This will greatly reduce the initial load on the JIT compiler, reducing its interference with the application, in configurations with fewer cores.
May be: "reducing its interference with the application during startup, particularly in configurations with fewer cores."
---
I agree that `(Delete this digression?)` should be removed. It describes how JIT compiler works. May be put it into wiki when you have time: https://wiki.openjdk.org/display/HotSpot/Compiler
----
Description
Even when peak performance requires additional JIT activity (to generate T4 code),
T4 is unknown. May be "new optimized code"?
(If you run a typical Java application with the option -XX:+PrintCompilation, and search for the string “made not entrant”, you will see many instances of the JIT replacing methods.)
It is too specific for this JEP. I don't think we need it.
May be also mention that we record execution environment during training run (CPU's features, VM's flags) and compare them with environment during production run and completely discard AOT code if they don't match.
---
AOT code implementation details
I think it should be moved to Implementation RFE. It is too technical for JEP.
The AOT code tier A3 works the same as the JIT tier T3: It runs at a low optimization level, but collects the same kind of profile information that the VM interpreter gathers.
We don't cache T3.
---- Alternatives
Since AOT code can be loaded immediately on startup, it might seem that profiles in the AOT cache (added by JEP 515) are now useless. But they still have their role, when AOT code is replaced by the JIT.
As you mention in previous text, profiles trigger AOT code (A4) loading when all referenced in code classes are initialized. So you can't say that AOT profiles are useless for AOT code.
Thanks, Vladimir K
(Looking at the JEP text today, 13 Oct.) I took away an unflattering view of the JIT compiler: - Per the Summary, it "interferes" with the application during startup. - Per the Motivation, it is clueless without profile data. - It uses "many computing resources" during warmup, causing delays of "seconds or even minutes" ! - Compilation of optimized native code is "heavy work" ... maybe it's not completely stupid to do it in a monster pass at build/packaging time, eh? Ultimately I want to dial down the unflattery, and I want to get there by having the JEP explain something important: Why producing *optimized* native code is so hard. Consider the dear reader. The opening paragraph mentions "*best possible* native code" but that's easy to overlook as the perspective immediately turns to running the app and the role of profiles (as if a re-run of 515). The system is then extolled as "able to compile and install highly optimized native code", sounds good. Then suddenly profiles aren't enough because the JIT's resource consumption is just too great, warmup is slow, sorry. Instead of applauding profiles, we should build up the awesome responsibilities of the dynamic and colorful JIT. Look at how 515 explained "hot methods" on its way to profiles and solving the chicken-and-egg problem of peakperf<->prediction. I think this JEP should explain two or three issues with dynamic codegen on its way to solving the last remaining roadblock to fast warmup. And, before that, just as 483 opens with an aggressive pitch for dynamism, I think this JEP should open with an aggressive pitch for native code. Suggestion for the first line: "To run a Java application at maximum speed, the JVM must compile the application's bytecode to native code." The text would "work" if the next line is "But to obtain the best possible native code, we must first run the application." and thence a chicken-and-egg argument, but 515 already did that. Instead, the next line should unfold a story about the costs of compilation. Subsequent paragraphs can then pitch compiled code as the final piece of the AOT puzzle. Further, with profiles _and_ compiled code in the cache, HotSpot can spend more time triple-optimizing the compiled code that matters and no time re-optimizing the compiled code that doesn't matter, so perhaps subsequent warmups will be even faster than this one? (Seeking an analog to 515's "Profiles allow the JVM to both optimize hot methods and avoid optimizing cold methods; both conditions are necessary for peak performance.") Alex On 9/29/2025 7:18 PM, John Rose wrote:
I have updated the text for the AOT code JEP:
https://openjdk.org/jeps/8335368
I would appreciate any editorial comments.
My present goal is to come closer to the style of our previous JEPs, and also to reflect recent conversations about AOT code.
(That style is relatively non-technical and light on details, FTR. This is just the way things are with JEPs.)
The recent conversations involve discussions about different AOT code shapes (AP4 vs. A4) and concerns about ISA compatibility. Please remind me of other recent conversations that may also be applicable to this JEP.
Thanks!
— John
P.S. This is not urgent. I don’t think this JEP will be in the current release. But it is important!
participants (3)
-
Alex Buckley
-
John Rose
-
Vladimir Kozlov