RFR: 8368465: [leyden] Improve precompiler method selection code [v3]
Vladimir Kozlov
kvn at openjdk.org
Tue Dec 2 22:02:19 UTC 2025
On Tue, 2 Dec 2025 11:35:43 GMT, Aleksey Shipilev <shade 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.
-------------
PR Review Comment: https://git.openjdk.org/leyden/pull/99#discussion_r2582832469
More information about the leyden-dev
mailing list