September 2025 - leyden-dev

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

AOT code JEP text updated
by John Rose 13 Oct '25

13 Oct '25

I have updated the text for the AOT code JEP: https://openjdk.org/jeps/8335368 I would appreciate any editorial comments. My present goal is to come closer to the style of our previous JEPs, and also to reflect recent conversations about AOT code. (That style is relatively non-technical and light on details, FTR. This is just the way things are with JEPs.) The recent conversations involve discussions about different AOT code shapes (AP4 vs. A4) and concerns about ISA compatibility. Please remind me of other recent conversations that may also be applicable to this JEP. Thanks! — John P.S. This is not urgent. I don’t think this JEP will be in the current release. But it is important!

3 4

Leverage profiled compiled size to avoid aggressive inlining and code growth
by Fei Gao 08 Oct '25

08 Oct '25

Hi @leyden-dev<mailto:leyden-dev@openjdk.org> and @hotspot compiler<mailto:hotspot-compiler-dev@openjdk.java.net>, TL;DR https://github.com/openjdk/jdk/pull/27527 I proposed a PoC that explores leveraging profiled compiled sizes to improve C2 inlining decisions and mitigate code bloat. The approach records method sizes during a pre-run and feeds them back via compiler directives, helping to reduce aggressive inlining of large methods. Testing on Renaissance and SPECjbb2015 showed clear code size differences but no significant performance impact on either AArch64 or x86. An alternative AOT-cache-based approach was also evaluated but did not produce meaningful code size changes. Open questions remain about the long-term value of profiling given Project Leyden's direction of caching compiled code in AOT, and whether global profiling information could help C2 make better inlining decisions. 1. Motivation In the current C2 behavior, the inliner only considers the estimated inlined size [1] [2] of a callee if the method has already been compiled by C2. In particular, C2 will explicitly reject inlining in the following cases: Hot methods with bytecode size > FreqInlineSize (325) [3] Cold methods with bytecode size > MaxInlineSize (35) However, a common situation arises where a method's bytecode size is below 325, yet once compiled by C2 it produces a very large machine code body. If this method has not been compiled at the time its caller is being compiled, the inliner may aggressively inline it, potentially bloating the caller, even though an independent compiled copy might eventually exist. To mitigate such cases, we can make previously profiled compiled sizes available early, allowing the inliner to make more informed decisions and reduce excessive code growth. [1] https://github.com/openjdk/jdk/blob/0ba4141cb12414c08be88b37ea2a163aacbfa7d… [2] https://github.com/openjdk/jdk/blob/0ba4141cb12414c08be88b37ea2a163aacbfa7d… [3] https://github.com/openjdk/jdk/blob/0ba4141cb12414c08be88b37ea2a163aacbfa7d… 2. Proof of Concept To validate this idea, I created a proof-of-concept: https://github.com/openjdk/jdk/pull/27527 In this PoC: 1) A dumping interface was added to record C2-compiled method sizes, enabled via the `-XX:+PrintOptoMethodSize` flag. 2) A new attribute was introduced in InlineMatcher: _inline_instructions_size. This attribute stores the estimated inlined size of a method, sourced from a compiler directive JSON file generated during a prior profiling run. 3) The inliner was updated to use these previously profiled method sizes to prevent aggressive inlining of large methods. 3. How to Use To apply this approach to any workload, the workload must be run twice: 1) Pre-run: collect inlined sizes for all C2-compiled methods. 2) Product run: use the profiled method sizes to improve C2 inlining. Step 1 Profile method size (pre-run) Log the compiled method size: `-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:+PrintOptoMethodSize -XX:LogFile=logmethodsize.out` This will generate a log containing method size information from C2. Step 2 Generate the compiler directive file Use the provided Python script to extract method size info and generate a JSON file: `python3 extract_size_to_directives.py logmethodsize.out output_directives.json` This file contains estimated inlined sizes to guide inlining decisions in product run. If the same method is compiled multiple times, the script conservatively retains the smallest observed size. Note: Methods that are not accepted by the CompilerDirective format need to be excluded. Step 3 Use the compiler directive in a product run Pass the generated JSON to the JVM as a directive: `-XX:+UnlockDiagnosticVMOptions -XX:CompilerDirectivesFile=output_directives.json` This enables the inliner to make decisions using previously profiled method sizes, potentially avoiding aggressive inlining of large methods. Note: The patch reuses the existing `inline` directive attribute for inlining control. If multiple inline rules match the same method, only the first match is effective. 4. Testing I tested the following workloads using the method above and measured the code cache size with `-XX:+PrintCodeCache`. The results are shown below, compared against the mainline code. All statistics (min, max, median, mean) are based on three runs. (patch - mainline) / mainline 1) Renaissance.dotty Code size change: AArch64: ``` used min max median mean non-profiled -9.88% -8.13% -8.92% -8.98% profiled -0.73% -0.21% -0.40% -0.45% non-nmethods -15.20% -0.02% -14.92% -10.32% codecache -2.82% -2.88% -2.97% -2.89% max_used min max median mean non-profiled -9.88% -8.13% -8.92% -8.98% profiled 2.37% 1.41% 1.50% 1.76% non-nmethods -0.95% -1.73% -0.93% -1.21% codecache -0.35% -1.00% -0.95% -0.77% ``` X86: ``` used min max median mean non-profiled -9.72% -9.61% -9.36% -9.56% profiled -0.81% -0.90% -1.15% -0.95% non-nmethods -0.04% 0.04% -0.02% -0.01% codecache -2.94% -2.96% -3.11% -3.00% max_used min max median mean non-profiled -9.72% -9.61% -9.36% -9.56% profiled 2.32% 2.60% 2.51% 2.48% non-nmethods -0.63% -2.25% -1.28% -1.39% codecache -0.68% -0.59% -0.70% -0.66% ``` No significant performance changes were observed on either platform. 2) SPECjbb 2015 Code size change: AArch64: ``` used min max median mean non-profiled -1.00% -11.68% -12.73% -8.62% profiled 9.07% -6.93% -2.34% -0.29% non-nmethods 0.02% -0.02% 0.00% 0.00% codecache 2.98% -7.18% -5.35% -3.28% max_used min max median mean non-profiled -10.85% -11.68% -12.73% -11.76% profiled -2.09% -11.65% -1.26% -5.62% non-nmethods 0.13% -1.21% -0.16% -0.41% codecache -6.42% -6.33% -6.10% -6.29% ``` On the AArch64 platform, no significant performance changes were observed for either high-bound IR or max jOPS. For critical jOPS: ``` Min Median Mean Max Var% -2.45% -1.87% -2.45% -3.00% 1.9% ``` X86: ``` used min max median mean non-profiled -9.02% -9.65% -7.93% -8.87% profiled -6.09% -3.18% -4.52% -4.61% non-nmethods -0.02% 0.25% 0.04% 0.09% codecache -5.36% -4.75% -4.58% -4.90% max_used min max median mean non-profiled -4.03% -9.65% -7.93% -7.23% profiled -2.86% 1.16% -1.03% -0.93% non-nmethods 0.02% -0.08% 0.08% 0.01% codecache -0.23% -4.20% -3.70% -2.73% ``` No significant performance change was observed on x86 platform. 5. AOT cache The current procedure above requires three steps: a pre-run to record method sizes, a separate step to process the JSON file, and finally a product run using the profiled method sizes. This workflow may add extra burden to workload deployment. With JEP 515 [4], we can instead store the estimated inlined size in the AOT cache when ciMethod::inline_instructions_size() is called during the premain run, and later load this size from the AOT cache during the product run [5]. The store-load mechanism for inlined size can help reduce the overhead of recomputing actual sizes, but it does not provide the inliner with much additional information about the callee, since the compilation order in the product run generally follows that of the premain run, even if not exactly. To give the inliner more profiled information about callees, I tried another simple draft that records inlined sizes for more C2-compiled methods: https://github.com/openjdk/jdk/pull/27519/commits/ef5e61f3d68ad565ee11e2cc6… However, with this draft using the AOT cache, I did not observe any significant code size changes for any workloads. This may require further investigation. [4] https://openjdk.org/jeps/515 [5] https://github.com/openjdk/jdk/blob/0ba4141cb12414c08be88b37ea2a163aacbfa7d… 6 Questions 1) Relation to Project Leyden Project Leyden aims to enhance the AOT cache to store compiled code from training runs [6]. This suggests that we may eventually prefer to cache compiled code directly from the AOT cache rather than rely solely on JIT compilation. Given this direction, is it still worthwhile to invest further in using profiled method sizes as a means to improve inlining heuristics? Could such profiling provide complementary benefits even if compiled code is cached? 2) Global profiling information for C2 Should we consider leveraging profiled information stored in the AOT cache to give the C2 inliner a broader, more global view of methods, enabling better inlining decisions? For example, could global visibility into method sizes and call sites help address pathological cases of code bloat or missed optimization opportunities? [7] [6] https://openjdk.org/jeps/8335368 [7] https://wiki.openjdk.org/display/hotspot/inlining I'd greatly appreciate any feedback. Thank you for your time and consideration. Thanks, Fei IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

2 4

bye stable values, enter lazy constants
by Maurizio Cimadamore 03 Oct '25

03 Oct '25

Hi all, Per and I have been completed another round of preview of the Stable Value API. As you might have noticed, the name changed (again!) to LazyConstant 🙂 https://openjdk.org/jeps/526 In many ways, the new API is more similar to the old ComputedConstant API, as the imperative methods are gone: the only way to create a lazy constant is by providing a lambda expression at construction. The reason behind the change is that, after performing extensive experiments with the StableValue API, we have learned that: * Most use cases could be expressed with a caching supplier. This meant that in most cases developers never needed to interact with StableValue -- which seemed odd. * For low-level cases, the imperative API we provided was not low-level enough, as it still added significant synchronization and boxing costs. This made the API unsuitable to use in performance critical code (such as the ClassFile API). For these reasons we have decided to shift the design center of the API back to the most common, functional use cases, which led us to this simpler API. That said, the quest for a more fundamental building block is not over: we now have a clearer idea on how to expose "stable" access to regular fields/array elements, using a _new_ var handle access mode. Initial experiments look indeed promising: such an approach doesn't require the allocation of intermediate abstractions, and allows clients to decide if they want to pay for synchronization or not. As always, we are very thankful for all the feedback we have received so far, and we look forward for some more! Cheers Maurizio

4 14

RFR: 8368811: [Leyden] Use AOTRuntimeConstants table for card_table::_byte_map_base
by Vladimir Kozlov 03 Oct '25

03 Oct '25

Currently we use `Relocation` info to patch `card_table::_byte_map_base` referenced in compiled code. This is not completely correct since this is not address. We currently have special check in `AOTCodeCache::init2()` to skip AOT code generation and usage if `byte_map_base` is not relocatable [aotCodeCache.cpp#L341](https://github.com/openjdk/leyden/blob/premain/src/h… To avoid this we should use existing `AOTRuntimeConstants` table to load `byte_map_base` from it. I also added few missing loads `card_shift` from `AOTRuntimeConstants` table. Actually I am not sure why we have it in `AOTRuntimeConstants` table. From what I see, it is based on `GCCardSizeInBytes` flag [cardTable.cpp#L46](https://github.com/openjdk/leyden/blob/premain/src/hotsp… and never modified. The flags is not adjusted ergonomically. So we can simple record the flag in AOT code configuration and verify it when loading AOT code. @adinn what do you think about `card_shift` in `AOTRuntimeConstants` table? You added it there. Changes were testing tier1-5. ------------- Commit messages: - 8368811: [Leyden] Use AOTRuntimeConstants table for card_table::_byte_map_base Changes: https://git.openjdk.org/leyden/pull/102/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=102&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368811 Stats: 355 lines in 18 files changed: 203 ins; 113 del; 39 mod Patch: https://git.openjdk.org/leyden/pull/102.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/102/head:pull/102 PR: https://git.openjdk.org/leyden/pull/102

2 14

Updated benchmark numbers in premain README
by ioi.lam＠oracle.com 02 Oct '25

02 Oct '25

I've updated the benchmark numbers using the latest premain tip (as of 2025/09/30): https://github.com/openjdk/leyden/blob/premain/README.md#premain-aot-cache-… There's quite a bit of improvement due to the new compiler tuning changes by Aleksey. I also added a "2 cores only" mode to emulate microservices that are allocated very few CPUs. Here are the results of {premain AOT} vs {JDK 25, no CDS, no AOT}. Note that premain is generally much more beneficial with the 2 Cores Only case, except for PetClinic: Benchmark Desktop/Server Class (28 Cores) 2 Cores Only *---------------------------------------------------------------------------- *Helidon Quick Start 3.59x 4.11x ++ JavacBenchApp 50 source files 2.21x 3.17x ++++ Micronaut First App Demo 2.91x 4.90x +++++++ Quarkus Getting Started Demo 2.97x 3.74x +++ Spring-boot Getting Started Demo 4.13x 4.70x ++ Spring PetClinic Demo 3.33x 3.03x -- ??? Changes from last time ( https://github.com/openjdk/leyden/blob/46e03d000efd1b2784ad4dcd4c83310ace49… ) The 2 Core Only case see a lot of improvements with the compiler tuning. PetClinic is again an outlier. Benchmark Desktop/Server Class (28 Cores) 2 Cores Only ---------------------------------------------------------------------------- Helidon Quick Start 3.60 -> 3.59x ~ 3.53 -> 4.11x ++ JavacBenchApp 50 source files 2.17 -> 2.21x ~ 2.74 -> 3.17x ++ Micronaut First App Demo 2.85 -> 2.91x + 4.39 -> 4.90x ++ Quarkus Getting Started Demo 2.73 -> 2.97x ++ 2.95 -> 3.74x +++ Spring-boot Getting Started Demo 3.96 -> 4.13x ++ 3.70 -> 4.70x +++ Spring PetClinic Demo 3.24 -> 3.33x + 3.04 -> 3.03x ~ (The +, -, ~ are calculated by my eyeballs so not very scientific :-)

2 2

git: openjdk/leyden: premain: 2 new changesets
by Ioi Lam 30 Sep '25

30 Sep '25

Changeset: 8a1fc0c9 Branch: premain Author: Ioi Lam <iklam(a)openjdk.org> Date: 2025-09-30 10:48:40 +0000 URL: https://git.openjdk.org/leyden/commit/8a1fc0c9f8a6825540ee40c951eed5bf4ee74… Updated benchmarks up to 7b7084b5ecb5ae978209434216e84ddf0ad81f5e ! README.md + test/hotspot/jtreg/premain/bench_data/bench.20250930.txt + test/hotspot/jtreg/premain/bench_data/digest.tcl + test/hotspot/jtreg/premain/bench_data/do_bench.sh ! test/hotspot/jtreg/premain/lib/GithubMDChart.java Changeset: 0af48c89 Branch: premain Author: Ioi Lam <iklam(a)openjdk.org> Date: 2025-09-30 11:53:48 +0000 URL: https://git.openjdk.org/leyden/commit/0af48c891d742c35ac7eb25abcf59d7ce9c8a… Added benchmark data for 2 Cores Only ! README.md + test/hotspot/jtreg/premain/bench_data/bench.20250930-2cpu.txt ! test/hotspot/jtreg/premain/bench_data/digest.tcl

1 0

git: openjdk/leyden: premain: Minor cleanup and refactoring
by Ashutosh Mehra 29 Sep '25

29 Sep '25

Changeset: 7b7084b5 Branch: premain Author: Ashutosh Mehra <asmehra(a)openjdk.org> Date: 2025-09-29 18:26:36 +0000 URL: https://git.openjdk.org/leyden/commit/7b7084b5ecb5ae978209434216e84ddf0ad81… Minor cleanup and refactoring Reviewed-by: kvn ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp

1 0

RFR: Minor cleanup and refactoring
by Ashutosh Mehra 29 Sep '25

29 Sep '25

Removed unused parameter `aot_code_entry` in `ciEnv::register_method`. Removed `preload` local variable in `ciEnv::register_method` as it is always false. Refactored `ciEnv::is_compilation_valid` a bit. ------------- Commit messages: - Minor cleanup and refactoring Changes: https://git.openjdk.org/leyden/pull/101/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=101&range=00 Stats: 45 lines in 5 files changed: 6 ins; 24 del; 15 mod Patch: https://git.openjdk.org/leyden/pull/101.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/101/head:pull/101 PR: https://git.openjdk.org/leyden/pull/101

2 6