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

[Vladimir Kozlov]

On Fri, 17 Oct 2025 21:31:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 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.

I am not sure understand how different order of pre/AOT-compilation can affect performance of production run.
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).

The only explanation is that preload happens only when C2 compiler threads are initialized (Preload AOT code is C2 compiled code) and it happens simultaneously with C1 threads initialization which could be available sooner for C1 compilation than we finish preloading. Especially on small number of cores machines.  I did observed that we start loading A1 and A2 code first (even normal C1 compilations) before we start preload AP4. 

Is it what you are trying to solve here?

The invocation counters should be roughly the same for methods without loops (10000 to trigger C2 compilation). They could be different if code was deoptimized and run in interpreter.  The only difference id backedge counter. So in this sense you push methods with hot loop up front as we talked about in other comment. Which may affect performance but it would depend on application.

I agree with ordering by size (or time spant in compilation) but only for methods which did not have A1 or A2 code. Which should not be the case - if we have AP4 we will have A1 and A2 for it. I am still not convince by this.

May be  we should try to move `AOTCodeCache::preload_code()` just after `SystemDictionary::compute_java_loaders()` because it does not depend on training data. So we can have AP4 sooner.  MMaping directly into CodeCache will also speedup preloading - it is on our list to do.

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

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