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

[Vladimir Kozlov]

On Tue, 2 Dec 2025 21:30:18 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>> So while compilers are working through preloading the code, the application runs and can trigger compilations. Sorting preloading methods allows loading hottest code before that code transits to normal compilation. This is the problem I am trying to mitigate.
>> 
>> Okay, I think I can understand when compile ID may screw up us. If T4 compilation during training run happens several times for the same method due to deoptimization we will cache only last corresponding AP4:
>> 
>>       if (entry->for_preload()) {
>>         if (entry->not_entrant()) {
>>           // Skip not entrant preload code:
>> 
>> such entry will have high compile ID. We can keep early ID and used it for cached AP4 to avoid this.
>> 
>> Which leads to an other issue. In initial AOT code implementation I kept deoptimization counter for A4 and use it when search A4 to load in production run. We removed that counter but kept all versions of A4 but `find_entry()` will return first A4 it found which may have a lot more uncommon traps when latest A4 version. May be we should filter A4 the same way we do for AP4.
>
> By "blocking" I mean that we have only one AOT compiler thread to load AP4.

May be your change reduced number of AOT compiled nmethod in cache which allow faster processing.
Please run with `-Xlog:aot+codecache+init=debug -XX:+CITime` for production run to see how many AOT nmethods in AOT cache and how many were loaded/used.

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

PR Review Comment: https://git.openjdk.org/leyden/pull/99#discussion_r2582859309