AOT code JEP text updated

[Alex Buckley]

(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!