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

[Vladimir Kozlov]

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

>>> We bulk load all "Preload" AOT code - ordering does not matter for it. Even if we load in selected order. It is one thread which do loading and it is blocking (I actually playing with spreading this preload on all compiler threads - did not see much affect on startup).
>> 
>> Um, I don't think that's the case? Preloading is asynchronous. See `CompileBroker::compile_method`:
>> 
>> 
>>     bool is_blocking = ReplayCompiles                                             ||
>>                        !directive->BackgroundCompilationOption                    ||
>>                        (PreloadBlocking && (compile_reason == CompileTask::Reason_Preload));
>>     compile_method_base(method, osr_bci, comp_level, hot_count, compile_reason, requires_online_compilation, is_blocking, THREAD);
>> 
>> 
>> We have the option to _make_ preload blocking (`PreloadBlocking`), but it is turned off by default. We know enabling `+PreloadBlocking` is counter-productive, because it could easily take hundreds of milliseconds. 
>> 
>> 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.
>> 
>> Maybe the compilation policy should actually participate in preloading: i.e. if there is a hot code that transitions from T0 to any other level, attempt the preload first, in case normal preloading is lagging behind. That would be more intrusive, though, so as the conservative approach I would like to prioritize more profitable preload code first.
>
>> 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.

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

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