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

[Aleksey Shipilev]

On Fri, 17 Oct 2025 23:50:02 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.

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

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