RFR: 8377597: [Leyden] Improve peak performance when AOT code is used [v2]

[Aleksey Shipilev]

On Thu, 12 Feb 2026 01:43:27 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Currently some AOT code could be used for long time after startup. It could case peak performance regression because AOT code is conservative and have several restrictions on optimizations it can do.
>> 
>> Introduce AOT code entry counter to request JIT compilation and replace AOT code after some threshold is reached. Use invocation count of C2 code during training run as threshold for AOT code replacement during production run.
>> 
>> The counts collected during training run are scaled based on hyperbolic saturation curve formula:
>> 
>> 
>>    int scaled_limit = (AOTCodeInvokeBase + limit / (1.0 + limit / (100000.0 * AOTCodeInvokeScale)));
>> 
>> where `AOTCodeInvokeBase` (default 100.) and `AOTCodeInvokeScale` (default 1.) are diagnostic flags.
>> This scaling limits threshold to 100K for higher counts.
>> 
>> Here some results running JavacBanch JMH benchmark on linux-x64 (numactl -C 0-3 -m 0`)
>> 
>> 
>> java -jar javac.jar -f 1 -bm ss -wi 0 -i 100 JavacBench.helloWorld1k
>> 
>> 
>> <img width="781" height="466" alt="Screenshot 2026-02-10 at 1 25 30 PM" src="https://github.com/user-attachments/assets/58d973bf-9881-45d9-acb8-40b18ca02a06" />
>> 
>> 
>> <img width="486" height="178" alt="Screenshot 2026-02-10 at 1 22 24 PM" src="https://github.com/user-attachments/assets/19fff702-2302-4e43-a093-5c6981a069ba" />
>> 
>> ...
>> <img width="479" height="153" alt="Screenshot 2026-02-10 at 1 24 09 PM" src="https://github.com/user-attachments/assets/72e9d81d-bce2-482c-aaea-a32a192a8899" />
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

This *does* improve peak performance for my tests _for sure_, but still not fully there compared to non-AOT config, alas:


Baseline:
Compiled 200 files 100 times in 33522 ms
...
 94 = 30.483 ms  6.561 files per ms
 95 = 30.565 ms  6.543 files per ms
 96 = 30.462 ms  6.565 files per ms
 97 = 30.007 ms  6.665 files per ms
 98 = 29.467 ms  6.787 files per ms
 99 = 30.113 ms  6.642 files per ms

AOT:
Compiled 200 files 100 times in 33544 ms
...
 94 = 32.259 ms  6.200 files per ms
 95 = 32.211 ms  6.209 files per ms
 96 = 32.310 ms  6.190 files per ms
 97 = 32.454 ms  6.163 files per ms
 98 = 32.319 ms  6.188 files per ms
 99 = 32.237 ms  6.204 files per ms

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

PR Comment: https://git.openjdk.org/leyden/pull/110#issuecomment-3892151777