RFR: 8366681: [leyden] Precompile more C1 code [v3]

[Vladimir Ivanov]

On Wed, 17 Sep 2025 10:50:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> It is very profitable on all workloads I tried, so I would like to get this in.

It's a good justification for a stop-the-gap fix. But from a design perspective it doesn't look that attractive. Basically, you introduce 3rd version of code for hot code which is unconditionally generated, but it covers a rare case (at least, it's intended to be rare) when A4 code is invalidated during execution. So, you trade footprint for startup. 

The improvements you observe with the patch may be a signal there are inefficiencies in our current implementation. And fixing those will improve startup without sacrificing footprint.  
 
Some more thoughts:
* C1 and C2 compilations aren't equivalent, especially when it comes to inlining decisions; so, when the same method is compiled with C1, it won't necessarily cover the same amount of application code.  
* Why cache A2 and not A3? Invalidation of A4 code signals that training data is not representative and, most likely, reprofiling is needed anyway. Or maybe just a T4 recompilation is enough?
* AP4 is intended to eventually become a baseline version which can be used in a wide range of circumstances; switching back to AP4 version while waiting for T3/T4 recompilation task to finish fits that goal well. 
 
> Plus, what if AP4 still, despite our best efforts, traps?
Is it enough to justify one more cached version for every hot method? And, theoretically, C1-generated code can trap as well.    

Overall, proposed patch looks good as a stop-the-gap measure, but IMO longer term it doesn't fit current design well.

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

PR Comment: https://git.openjdk.org/leyden/pull/93#issuecomment-3304797955