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

[Dan Heidinga]

On Tue, 10 Feb 2026 21:26:09 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" />

src/hotspot/share/ci/ciMethod.cpp line 1142:

> 1140:     return CURRENT_ENV->get_method_counters(method_counters);
> 1141:   }
> 1142:   return nullptr;

The `CHECK_NULL` macro says if there's a pending exception, return null.  Does that imply that this function has a contract that if it returns `nullptr`, there will also be a pending exception?

src/hotspot/share/ci/ciObjectFactory.cpp line 426:

> 424:   } else if (o->is_methodCounters()) {
> 425:     // Hold methodHandle alive - might not be necessary ???
> 426:     methodHandle h_m(THREAD, ((MethodCounters*)o)->method());

Either `o` is kept alive already by something else, or the `methodHandle` here is insufficient.

If `o` is not already kept alive by something, it could be GC'd before the `methodHandle` is created and we'd be operating on invalid data.

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

PR Review Comment: https://git.openjdk.org/leyden/pull/110#discussion_r2795559419
PR Review Comment: https://git.openjdk.org/leyden/pull/110#discussion_r2795578433