RFR: 8368465: [leyden] Improve precompiler method selection code [v3]

[Aleksey Shipilev]

On Fri, 17 Oct 2025 17:14:54 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'premain' into JDK-8368465-precompiler-method-select
>>  - Merge branch 'premain' into JDK-8368465-precompiler-method-select
>>  - Touchup
>>  - Touchups
>>  - Fix
>
> src/hotspot/share/compiler/precompiler.cpp line 76:
> 
>> 74:       case CompLevel_full_profile:
>> 75:         // We do not include C1 full profiled methods at this time.
>> 76:         // TODO: See if it is profitable to do so. This requires MDO support in AOTCache.
> 
> We already support reference to MDO from C1 compiled code because we cache tier2 which do profiling.
> But we may miss few places in tier3 code.

I thought we only record MCS, and reinstantiating MDO. But my recollection is vague. I dropped this to avoid confusion.

> src/hotspot/share/compiler/precompiler.cpp line 124:
> 
>> 122:       MethodData* md = mtd->final_profile();
>> 123:       if (md != nullptr) {
>> 124:         count += md->backedge_count();
> 
> Hmm, this will put methods with hot loop up front.

Yes, this is intentional: this effectively puts the methods that are profitable to (pre)load first, so they: a) do not linger in interpreter too much; b) do not trigger JIT compilation before AOT code is able to (pre)load. The methods with hot back-branches are those methods :)

> src/hotspot/share/compiler/precompiler.cpp line 143:
> 
>> 141:     if (c1 < c2) return +1;
>> 142: 
>> 143:     // Otherwise, break the tie by code size: largest methods go first.
> 
> What is the reason for larger method be first? Can we use compile ID here instead?

So my logic was like with the hot methods. If we have lost the game of "preload the AOT code before JIT got triggered", and JIT got triggered, we want to then prioritize larger methods, as they are more likely to take more time to JIT compile. In other words, I think if you lost to JIT timing-wise, you want to preempt the fattest JIT compiles first. But it is only a bet. If we ever record compilation time in nmethods/profiles, we could have used that to break the tie.

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

PR Review Comment: https://git.openjdk.org/leyden/pull/99#discussion_r2441293292
PR Review Comment: https://git.openjdk.org/leyden/pull/99#discussion_r2441300763
PR Review Comment: https://git.openjdk.org/leyden/pull/99#discussion_r2441308216