December 2025 - leyden-dev

RFR: Experiment with storing target method for static and opt-virtual callsites in reloc info
by Ashutosh Mehra 05 Feb '26

05 Feb '26

This work aims to reduce the time taken to perform call resolution by caching the result of direct calls (static and opt-virtual) in the reloc info during compilation of a method. Relocations for static and opt-virtual calls already have a field `method_index` which is used to store the "real" method to be invoked by the method handle. It is currently only used during c2 compilations. This patch re-uses the `method_index` field for static and opt-virtual calls to store the target method. The runtime call (`SharedRuntime::resolve_helper`) used by the compiled code to perform the call site resolution can then optimize the resolution process by getting the target method from the reloc info and patches the callsite through CompiledDirectCall. No special handling is needed for AOT code. On a 4-cpu system there is around 3% improvement in `spring-boot-getting-started`. Numbers for JavacBench range between 0-3% improvement. `spring-boot-getting-started`: Run,Old CDS + AOT,New CDS + AOT 1,199,192 2,199,196 3,202,197 4,203,198 5,198,196 6,201,194 7,203,197 8,200,193 9,204,193 10,199,201 Geomean,200.79,195.68 (1.03x improvement) Stdev,1.99,2.61 `-Xlog:init` shows the numbers for time spent in call resolution from the compiled code. For `spring-boot-getting-started` before this patch: [0.357s][info][init] SharedRuntime: [0.357s][info][init] resolve_opt_virtual_call: 8260us / 2249 events [0.357s][info][init] resolve_virtual_call: 6899us / 1297 events [0.357s][info][init] resolve_static_call: 4646us / 1723 events [0.357s][info][init] handle_wrong_method: 680us / 145 events [0.357s][info][init] ic_miss: 2109us / 488 events [0.357s][info][init] Total: 22596us [0.357s][info][init] perf_resolve_static_cache_hit_ctr: 0 [0.357s][info][init] perf_resolve_opt_virtual_cache_hit_ctr: 0 For `spring-boot-getting-started` after this patch: [0.348s][info][init] SharedRuntime: [0.348s][info][init] resolve_opt_virtual_call: 2774us / 2251 events [0.348s][info][init] resolve_virtual_call: 5577us / 1294 events [0.348s][info][init] resolve_static_call: 1901us / 1728 events [0.348s][info][init] handle_wrong_method: 719us / 146 events [0.348s][info][init] ic_miss: 2109us / 474 events [0.348s][info][init] Total: 13082us [0.348s][info][init] perf_resolve_static_cache_hit_ctr: 1704 [0.348s][info][init] perf_resolve_opt_virtual_cache_hit_ctr: 2202 For JavacBench before this patch: [0.406s][info][init] SharedRuntime: [0.406s][info][init] resolve_opt_virtual_call: 7146us / 2354 events [0.406s][info][init] resolve_virtual_call: 7160us / 2207 events [0.406s][info][init] resolve_static_call: 2992us / 1264 events [0.406s][info][init] handle_wrong_method: 728us / 186 events [0.406s][info][init] ic_miss: 2389us / 675 events [0.406s][info][init] Total: 20416us [0.406s][info][init] perf_resolve_static_cache_hit_ctr: 0 [0.406s][info][init] perf_resolve_opt_virtual_cache_hit_ctr: 0 For JavacBench after this patch: [0.399s][info][init] SharedRuntime: [0.399s][info][init] resolve_opt_virtual_call: 2321us / 2346 events [0.399s][info][init] resolve_virtual_call: 7452us / 2213 events [0.399s][info][init] resolve_static_call: 1264us / 1258 events [0.399s][info][init] handle_wrong_method: 747us / 177 events [0.399s][info][init] ic_miss: 2395us / 665 events [0.399s][info][init] Total: 14180us [0.399s][info][init] perf_resolve_static_cache_hit_ctr: 1212 [0.399s][info][init] perf_resolve_opt_virtual_cache_hit_ctr: 2236 ------------- Commit messages: - Experiment with storing target method for static and opt-virtual call sites in reloc info Changes: https://git.openjdk.org/leyden/pull/106/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=106&range=00 Stats: 231 lines in 22 files changed: 156 ins; 7 del; 68 mod Patch: https://git.openjdk.org/leyden/pull/106.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/106/head:pull/106 PR: https://git.openjdk.org/leyden/pull/106

3 7

Initialization code that never got trained
by María Arias de Reyna Dominguez 04 Feb '26

04 Feb '26

Happy New Year! I have been doing some experiments with Leyden and realized something: there is some code at startup/initialization that never gets optimized but is impacting on startup and warmup time. This was a realization while doing comparisons with native/graalvm images of the same code. For example: a REST API. It has some initialization, port opening, reading configurations, etc... that run only once. So the code will never be trained. But it always runs at startup, impacting the time to first response. Compared to a native image, the native image may not have it optimized, but at least it is already compiled, not interpreted. Therefore, the native image starts faster. So, how can I tell Leyden to please compile and cache those functions, even if they are going to be run just once, even if they are not optimized at all, even if those compilations can get discarded after a couple of seconds? Or are we just going to assume that that code, which is impacting startup time, doesn't need to be pre-compiled because we are focusing only on optimizations made by the JVM on runtime? Kind regards, María Arias de Reyna Domínguez Senior Software Engineer She / Her / Hers ariasdereyna(a)redhat.com

3 5

RFR: 8366681: [leyden] Precompile more C1 code
by Aleksey Shipilev 03 Feb '26

03 Feb '26

Looking at how code goes through AOT+JIT pipeline, I believe we have several issues in the way we include the methods for precompilation. 1. AP4 code gets replaced by more efficient A4 code, which can then deopt. Once it does, we go back to the fully normal JIT pipeline, with C1 compiling, C2 compiling, etc. Training run currently does A2 versions only when there is a tier2/3 training data present. We can pessimistically assume that A4/AP4 method should have A2 method generated for the sake of quicker deopt. 2. I suspect a similar thing, but rarer, happens with A4 -> ... -> T1 transition when compiler queues are overloaded. We can generate A1 method for this case. 3. When training is done with default configuration, but at runtime we enable only C1, we summarily miss almost *all* AOT methods, because A1 methods are rarely generated with a normal tiered policy. Generating A1 methods always would be convenient for hybrid C2 AOT + C1 JIT modes as well. Overall, I think generating more C1 methods even when C2 methods are present in training is beneficial, as we prepare the ground for whatever corner case happens at runtime. Benchmarks show this improves performance model quite a bit. Since we now look at methods at all different tiers when deciding to precompile, compile IDs are not working all that well. I have rewritten that to use counters and method sizes. This seems to work well in practice. Additional testing: - [x] `javac` performance tests (see comments) - [x] Linux x86_64 server fastdebug, `runtime/cds` ------------- Commit messages: - Fix Changes: https://git.openjdk.org/leyden/pull/93/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=93&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366681 Stats: 121 lines in 4 files changed: 64 ins; 27 del; 30 mod Patch: https://git.openjdk.org/leyden/pull/93.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/93/head:pull/93 PR: https://git.openjdk.org/leyden/pull/93

4 15

RFR: 8373256: [leyden] Pack DataKind more densely in archive
by Aleksey Shipilev 03 Feb '26

03 Feb '26

Spotting a little inefficiency when looking at related code. `DataKind` is always stored as `int`, but its values are actually comfortably fitting in byte. Going to `int8_t` saves about 1% of AOT cache size. If this ever becomes a problem, we can always revert back to `int32_t`. I looked around other uses of `write_bytes`, and I believe `DataKind` is the most obvious opportunity. Additional testing: - [x] Linux x86_64 server fastdebug, `runtime/cds` ------------- Commit messages: - Fix Changes: https://git.openjdk.org/leyden/pull/105/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=105&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373256 Stats: 23 lines in 2 files changed: 0 ins; 0 del; 23 mod Patch: https://git.openjdk.org/leyden/pull/105.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/105/head:pull/105 PR: https://git.openjdk.org/leyden/pull/105

3 3

Does it make sense to tweak compilation for training?
by María Arias de Reyna Dominguez 16 Dec '25

16 Dec '25

Hi! While searching for good documentation to link to when explaining Leyden, I found this (rather old) page: https://www.ibm.com/docs/en/sdk-java-technology/8?topic=options-xjit-xnojit with compilation options I didn't know existed. And I was wondering: does it make sense to force some things during training run to make sure we get the best training? I'm thinking for example on forcing a high level of compilation on some methods, so we arrive to production with more things optimized. Or excluding some "testing framework" methods from compilation. Or is it better not to touch anything and let Java run normally because this may become too unpredictable? Or... should I play with this and see what happens because we don't really know? :) Kind regards, María Arias de Reyna Domínguez Senior Software Engineer She / Her / Hers ariasdereyna(a)redhat.com

4 3

git: openjdk/leyden: premain: 8368465: [leyden] Improve precompiler method selection code
by Aleksey Shipilev 05 Dec '25

05 Dec '25

Changeset: 9c83531e Branch: premain Author: Aleksey Shipilev <shade(a)openjdk.org> Date: 2025-12-05 18:33:47 +0000 URL: https://git.openjdk.org/leyden/commit/9c83531e88020f5762116020bcf472511058c… 8368465: [leyden] Improve precompiler method selection code Reviewed-by: kvn ! src/hotspot/share/compiler/precompiler.cpp ! src/hotspot/share/compiler/precompiler.hpp

1 0

RFR: 8368465: [leyden] Improve precompiler method selection code
by Aleksey Shipilev 05 Dec '25

05 Dec '25

Forked from [JDK-8366681](https://bugs.openjdk.org/browse/JDK-8366681): there are still some cleanups/performance improvements possible. Current selection code is a bit hairy, and turns out the changes I made for previous patch improve performance. Notable improvements: 1. Push the compilation level filters downwards. This allows compiling A2 from T2/T3 code more easily, and allows to implement policies for compiling on any A* level based on observing top-compiled T* levels. 2. Sort methods by hotness and code size. This avoids a fairly awkward path to get compile IDs, ditching which _I suspect_ is the cause for performance improvement. With new code, we compile a tad more A2 code. I have not digged through why current code accepts fewer methods for compilation. New code improves performance everywhere, so I suggest we just accept that and move on. Additional testing: - [x] Performance tests (see comments) - [x] Linux x86_64 server fastdebug, `runtime/cds` ------------- Commit messages: - Fix Changes: https://git.openjdk.org/leyden/pull/99/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=99&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368465 Stats: 116 lines in 4 files changed: 59 ins; 27 del; 30 mod Patch: https://git.openjdk.org/leyden/pull/99.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/99/head:pull/99 PR: https://git.openjdk.org/leyden/pull/99

2 28

Redundant MethodCounters in preimage
by Ashutosh Mehra 04 Dec '25

04 Dec '25

Hi, While working on the leyden-analyzer tool Maria mentioned that MethodCounters for a particular method is present in the preimage generated by the training run but not in the final AOT Cache generated by the assembly phase. In fact the number of MethodCounters in the preimage is way more than that in the final image. For an app that Maria was using, map file for training phase shows: $ grep "@@ MethodCounters " t.map |wc -l 22495 and the map file for assembly phase shows: $ grep "@@ MethodCounters " a.map |wc -l 8701 I checked the code and realized there are two ways MethodCounters can get into the cache: 1. through Method (see Method::metaspace_pointers_do) 2. through MethodTrainingData (see MethodTrainingData::metaspace_pointers_do) The first point explains the presence of so many MethodCounters, because any method that gets executed would have its MethodCounters added to the cache. Interestingly the link between Method and MethodCounters is then severed in Method::unlink_method(). That means the Methods adopted from the preimage in the assembly phase do not have MethodCounters. And since we don't execute the application, we don't create MethodCounters for the Methods loaded from the preimage. Only the MethodCounters discoverable via MethodTrainingData seep into the AOTCache. >From the above explanation it looks like not every MethodCounters added to the preimage is useful. Probably we should only be adding MethodCounters through the MethodTrainingData and not through Method. This would also reduce the size of the preimage a bit. In this particular case MethodCounters size was 1437824 bytes in preimage and 551552 bytes in the AOT Cache. Does this make sense? Thanks, - Ashutosh Mehra

2 2