January 2026 - leyden-dev

Integrity violation in AOTCache
by Aman Sharma 24 Feb '26

24 Feb '26

Hi all, I have been playing around with AOTCache and I tried a small with it experiment whose idea was to shadow a class using AOTCache. By class shadowing, I mean loading a different class than intended but they both share the same fully qualified name. We also explored this concept in the paper: Maven-Hijack: Software Supply Chain Attack Exploiting Packaging Order<https://arxiv.org/abs/2407.18760v4>, and now I am trying to extend it to AOTCache. The steps in the experiment are based on POC<https://github.com/chains-project/maven-hijack-poc> from the same paper and are written briefly below. The exact commands are documented here<https://github.com/chains-project/maven-hijack-poc/blob/main/java/maven/abs…>. 1. Build the application with one of the dependencies having malicious class. The malicious class has the same name as one of the other classes, say `org.postrgresql.Driver` but has malicious contents<https://github.com/chains-project/maven-hijack-poc/blob/0310de24103a55d1f51…>. 2. Create an AOTCache using these dependencies in jar. This creates a "polluted AOTCache". 3. Now using the polluted cache, run the application that is packaged with genuine dependencies. Apparently, the JVM initializes the malicious class from AOTCache instead of loading it from classpath. In other words, `java -XX:AOTCache=maven.aot -jar target/victim-1.0.jar` and `java -jar target/victim-1.0.jar` give different outputs. I see this as a weakness if the poisoned AOTCache is distributed as an artifact for consumers to be used because maybe it is not expected from consumers to perform a training run themselves. I believe there should be some sort of integrity checks before a class is initialized from AOTCache. I noticed there are already some<https://github.com/openjdk/jdk/blob/e3b5b261af6acbe7ab074f301c70283b06c17d3…> (please share if there are more, and I have missed them), but none of them relate to what I am mentioning. I am happy to listen to some thoughts on this. Regards, Aman Sharma PhD Student KTH Royal Institute of Technology School of Electrical Engineering and Computer Science (EECS) Department of Theoretical Computer Science (TCS) <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/

4 7

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

git: openjdk/leyden-docs: master: Adding latest talk to the list (JChampions 2026)
by Aleksey Shipilev 30 Jan '26

30 Jan '26

Changeset: f1c784ba Branch: master Author: María Arias de Reyna Domínguez <726590+Delawen(a)users.noreply.github.com> Committer: Aleksey Shipilev <shade(a)openjdk.org> Date: 2026-01-30 14:12:21 +0000 URL: https://git.openjdk.org/leyden-docs/commit/f1c784baeb9ea33aec9581e0d4867cd5… Adding latest talk to the list (JChampions 2026) ! site/_index.md

1 0

RFR: Adding latest talk to the list (JChampions 2026)
by María Arias de Reyna Domínguez 30 Jan '26

30 Jan '26

Adding a new talk to the list of talks --------- ### Progress - [x] Change must not contain extraneous whitespace ### Error  ⚠️ The pull request body must not be empty. ### Reviewing <details><summary>Using <code>git</code></summary> Checkout this PR locally: \ `$ git fetch https://git.openjdk.org/leyden-docs.git pull/6/head:pull/6` \ `$ git checkout pull/6` Update a local copy of the PR: \ `$ git checkout pull/6` \ `$ git pull https://git.openjdk.org/leyden-docs.git pull/6/head` </details> <details><summary>Using Skara CLI tools</summary> Checkout this PR locally: \ `$ git pr checkout 6` View PR using the GUI difftool: \ `$ git pr show -t 6` </details> <details><summary>Using diff file</summary> Download this PR as a diff file: \ <a href="https://git.openjdk.org/leyden-docs/pull/6.diff">https://git.openjdk.org/leyden-docs/pull/6.diff</a> </details> ------------- Commit messages: - Adding latest talk to the list (JChampions 2026) Changes: https://git.openjdk.org/leyden-docs/pull/6/files Webrev: https://webrevs.openjdk.org/?repo=leyden-docs&pr=6&range=00 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/leyden-docs/pull/6.diff Fetch: git fetch https://git.openjdk.org/leyden-docs.git pull/6/head:pull/6 PR: https://git.openjdk.org/leyden-docs/pull/6

2 2

RFR: Moving JEP 516 to Delivered
by María Arias de Reyna Domínguez 30 Jan '26

30 Jan '26

Updating the list of delivered JEPs. ------------- Commit messages: - Moving JEP 516 to Delivered Changes: https://git.openjdk.org/leyden-docs/pull/5/files Webrev: https://webrevs.openjdk.org/?repo=leyden-docs&pr=5&range=00 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.org/leyden-docs/pull/5.diff Fetch: git fetch https://git.openjdk.org/leyden-docs.git pull/5/head:pull/5 PR: https://git.openjdk.org/leyden-docs/pull/5

3 4

git: openjdk/leyden-docs: master: Moving JEP 516 to Delivered
by Aleksey Shipilev 30 Jan '26

30 Jan '26

Changeset: 7b411e7d Branch: master Author: María Arias de Reyna Domínguez <726590+Delawen(a)users.noreply.github.com> Committer: Aleksey Shipilev <shade(a)openjdk.org> Date: 2026-01-30 14:05:50 +0000 URL: https://git.openjdk.org/leyden-docs/commit/7b411e7d1d8f9706c6a8a9582e0417a6… Moving JEP 516 to Delivered ! site/_index.md

1 0

Using AOTCaching with debug (JDWP)
by Anthony Dahanne 30 Jan '26

30 Jan '26

Hello all! I'm trying to run an AOTCaching optimized app in debug mode; unfortunately, it does not seem to be supported. Using a JDK 25.0.1, during the training run I have: ``` [creator] Temporary AOTConfiguration recorded: application.aot.config [creator] Launching child process /layers/paketo-buildpacks_bellsoft-liberica/jre/bin/java to assemble AOT cache application.aot using configuration application.aot.config [creator] Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=runner.jar:lib/spring-cloud-bindings-2.0.4.jar -agentlib:jdwp=transport=dt_socket,server=y,address=*:8000,suspend=n -XX:+AOTClassLinking -Dspring.context.exit=onRefresh -XX:AOTCacheOutput=application.aot -XX:AOTConfiguration=application.aot.config -XX:AOTMode=create [creator] Reading AOTConfiguration application.aot.config and writing AOTCache application.aot [creator] [0.262s][warning][aot] Skipping io/micrometer/core/instrument/config/InvalidConfigurationException: Unlinked class not supported by AOTClassLinking [creator] [0.262s][warning][aot] Skipping org/springframework/web/servlet/view/freemarker/FreeMarkerView: Unlinked class not supported by AOTClassLinking [creator] [0.262s][warning][aot] Skipping org/springframework/boot/logging/log4j2/Log4J2LoggingSystem: Unlinked class not supported by AOTClassLinking [creator] [0.263s][warning][aot] Skipping org/springframework/core/ReactiveAdapterRegistry$ReactorAdapter: Unlinked class not supported by AOTClassLinking [creator] AOTCache creation is complete: application.aot 56819712 bytes [creator] Removed temporary AOT configuration file application.aot.config ``` but at runtime, I have: ``` Picked up JAVA_TOOL_OPTIONS: -Djava.security.properties=/layers/paketo-buildpacks_bellsoft-liberica/java-security-properties/java-security.properties -XX:+ExitOnOutOfMemoryError -agentlib:jdwp=transport=dt_socket,server=y,address=*:8000,suspend=n -XX:MaxDirectMemorySize=10M -Xmx14945375K -XX:MaxMetaspaceSize=78944K -XX:ReservedCodeCacheSize=240M -Xss1M -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary -XX:+PrintNMTStatistics -XX:AOTCache=application.aot -Dorg.springframework.cloud.bindings.boot.enable=true [0.032s][error][aot] AOT cache has aot-linked classes. It cannot be used with JDWP agent [0.034s][error][aot] An error has occurred while processing the AOT cache. Run with -Xlog:aot for details. [0.034s][error][aot] Unable to map shared spaces Listening for transport dt_socket at address: 8000 ``` If I enable `-Xlog:aot` at runtime, I have: ``` Picked up JAVA_TOOL_OPTIONS: -Xlog:aot -Djava.security.properties=/layers/paketo-buildpacks_bellsoft-liberica/java-security-properties/java-security.properties -XX:+ExitOnOutOfMemoryError -agentlib:jdwp=transport=dt_socket,server=y,address=*:8000,suspend=n -XX:MaxDirectMemorySize=10M -Xmx15196043K -XX:MaxMetaspaceSize=78944K -XX:ReservedCodeCacheSize=240M -Xss1M -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary -XX:+PrintNMTStatistics -XX:AOTCache=application.aot -Dorg.springframework.cloud.bindings.boot.enable=true [0.033s][info][aot] trying to map application.aot [0.033s][info][aot] Opened AOT cache application.aot. [0.033s][info][aot] The AOT cache was created with UseCompressedOops = 1, UseCompressedClassPointers = 1, UseCompactObjectHeaders = 0 [0.033s][info][aot] Core region alignment: 65536 [0.033s][info][aot] ArchiveRelocationMode: 1 [0.033s][info][aot] ArchiveRelocationMode == 1: always map archive(s) at an alternative address [0.033s][info][aot] Try to map archive(s) at an alternative address [0.033s][info][aot] Reserved archive_space_rs [0x0000003000000000 - 0x0000003004000000] (67108864) bytes (includes protection zone) [0.033s][info][aot] Reserved class_space_rs [0x0000003004000000 - 0x0000003008000000] (67108864) bytes [0.033s][info][aot] Mapped static region #0 at base 0x0000003000010000 top 0x0000003001500000 (ReadWrite) [0.033s][info][aot] Mapped static region #1 at base 0x0000003001500000 top 0x0000003003200000 (ReadOnly) [0.033s][info][aot] Mapped static region #2 at base 0x0000ffff5c120000 top 0x0000ffff5c1e0000 (Bitmap) [0.069s][info][aot] archived module property jdk.module.main: (null) [0.069s][info][aot] archived module property jdk.module.addexports: (null) [0.069s][info][aot] archived module property jdk.module.addmods: (null) [0.069s][info][aot] archived module property jdk.module.enable.native.access: (null) [0.069s][info][aot] archived module property jdk.module.addopens: (null) [0.069s][info][aot] archived module property jdk.module.addreads: (null) [0.069s][info][aot] optimized module handling: enabled [0.069s][info][aot] full module graph: enabled [0.069s][error][aot] AOT cache has aot-linked classes. It cannot be used with JDWP agent [0.069s][info ][aot] Unmapping region #0 at base 0x0000003000010000 (ReadWrite) [0.069s][info ][aot] Region #0 (ReadWrite) is in a reserved space, it will be freed when the space is released [0.069s][info ][aot] Unmapping region #1 at base 0x0000003001500000 (ReadOnly) [0.069s][info ][aot] Region #1 (ReadOnly) is in a reserved space, it will be freed when the space is released [0.069s][info ][aot] Unmapping region #2 at base 0x0000ffff5c120000 (Bitmap) [0.069s][error][aot] An error has occurred while processing the AOT cache. Run with -Xlog:aot for details. [0.069s][error][aot] Unable to map shared spaces Listening for transport dt_socket at address: 8000 ``` I have tried several variations using ` -XX:+AOTClassLinking` during the training run, but that did not change a thing. Is it possible to use AOTCaching when debug is enabled? Thank you!

3 4