RFR: 8368321: Rethink compilation delay strategy for lukewarm methods

[Igor Veresov]

In the current implementation we delay profiling of lukewarm methods (those that were never compiled by C2 during training) by increasing the 2->3 threshold by a factor. That may shift profiling of those too much into the future if a large factor is used, if we use a small factor, however, profiling may happen within the training run window so to speak. The solution I came up with it to delay profiling until we reach the number of invocations of a method equal to the number we had in the training run. After that we use the normal policy.

Here is an example. I trained our JavacBenchApp for 5 iterations (which is artificially low and therefore many methods would be classified as lukewarm). Then I ran it for 200 iterations with AOT replay.

<img width="640" height="480" alt="old-vs-new" src="https://github.com/user-attachments/assets/7f758dc1-ad6d-4ae5-8519-ddab18410722" />

While initially the performance is similar it quickly diverges. With the new approach we move to standard handling of lukewarm methods after 5 iterations and they get compiled with C2. With the old approach we don't.

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

Commit messages:
 - Delay lukewarmp methods based on training data

Changes: https://git.openjdk.org/jdk/pull/27926/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27926&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368321
  Stats: 69 lines in 5 files changed: 33 ins; 15 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/27926.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27926/head:pull/27926

PR: https://git.openjdk.org/jdk/pull/27926