February 2025 - leyden-dev

git: openjdk/leyden: premain: 8349181: [leyden] tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails
by Ioi Lam 06 Feb '25

06 Feb '25

Changeset: c6802a84 Branch: premain Author: Aleksey Shipilev <shade(a)openjdk.org> Committer: Ioi Lam <iklam(a)openjdk.org> Date: 2025-02-06 18:26:39 +0000 URL: https://git.openjdk.org/leyden/commit/c6802a8415325b0ab91bc15f3f4171058ce8f… 8349181: [leyden] tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails Reviewed-by: iklam ! src/java.base/share/classes/java/lang/System.java

1 0

RFR: Save/load i2c2i adapters
by Ashutosh Mehra 05 Feb '25

05 Feb '25

This is an attempt to save and load i2c2i adapters along with the adapter handler table. There are mainly two parts to this change: 1. Storing of adapter code in the SCCache or AOT code cache. 2. Storing of adapter handler table in the AOT cache. Adapter handler table is a map from AdapterFingerPrint to AdapterHnadlerEntry. To store them in AOT cache, AdapterFingerPrint and AdapterHandlerEntry are updated to MetaspaceObj. Both these entities are discovered and added to the cache while processing the Method. When storing the adapter handler table, only the entries that have already been archived are considered. This allows pruning of AdapterHnadlerEntry that may be only reachable through a Method that is not eligible to be archived. An AdapterHandlerEntry has pointer to the adapter code. Because the AdapterHandlerEntry and the adapter code are stored in separate archives, this link between the AdapterHandlerEntry and the adapter code needs to be removed (see AdapterHandlerEntry::remove_unshareable_info()). During the production run, as the methods in the AOT cache are adopted, the AdapterHandlerEntry is linked back to the adapter code (see AdapterHandlerEntry::restore_unshareable_info). All this code is guarded by -XX:[+-]ArchiveAdapters option which defaults to false, but is set to true in CDSConfig during the assembly phase. Other changes worth mentioning: 1. Changes to the SCCache infrastructure to make it possible to store and load adapter code. (Thanks to @adinn) 2. Updating AdapterFingerPrint hashing algorithm to avoid collisions. If there is any collision, then it will prevent finding the adapter code in the SCCache. (Again courtesy of @adinn) Thanks to @adinn for providing many of these changes. Performance: -Xlog:init shows time taken for linking of Methods and making adapters. An example output is: ClassLoader: clinit: 150us / 4612 events link methods: 28980us / 176893 events method adapters: 15378us / 697 events Save/load of adapters seem to have improved these stats. | Quarkus | -ArchiveAdapters | +ArchiveAdapters | |---|---|---| | link methods | 12214us / 58913 events | 2700us / 58913 events | | method adapters | 7793us / 607 events | 4402us / 38 events | | Spring-petclinic | -ArchiveAdapters | +ArchiveAdapters | |---|---|---| | link methods | 28980us / 176893 events | 7485us / 176893 events | | method adapters | 15378us / 697 events | 7050us / 13 events | However, testing with Quarkus app, I don't see any noticeable improvement in the startup time. ------------- Commit messages: - More whitespace fixes - Move the check for is_abstract_method_adapter() to correct place - Surround code with INCLUDE_CDS where appropriate - Fix whitespace issues - Fix compile failures - Fix a bug and add comment in AdapterHandlerEntry::restore_unshareable_info() - Refactor code to avoid calling AdapterFingerPrint::as_basic_type() when - Add a helper method to iterate over AdapterFingerPrint - Improve hashing algorithm for AdapterFingerPrint - Misc changes - ... and 10 more: https://git.openjdk.org/leyden/compare/a1672ea6...04fb256b Changes: https://git.openjdk.org/leyden/pull/25/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=25&range=00 Stats: 1293 lines in 25 files changed: 834 ins; 248 del; 211 mod Patch: https://git.openjdk.org/leyden/pull/25.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/25/head:pull/25 PR: https://git.openjdk.org/leyden/pull/25

5 41

git: openjdk/leyden: premain: Save/load i2c2i adapters
by Ashutosh Mehra 05 Feb '25

05 Feb '25

Changeset: 7a61e391 Branch: premain Author: Ashutosh Mehra <asmehra(a)openjdk.org> Date: 2025-02-05 18:42:09 +0000 URL: https://git.openjdk.org/leyden/commit/7a61e39199d8c119f66f5088b067fc57a62d1… Save/load i2c2i adapters Co-authored-by: Andrew Dinn <adinn(a)openjdk.org> Reviewed-by: kvn, iklam ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/zero/sharedRuntime_zero.cpp ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/cdsConfig.cpp ! src/hotspot/share/cds/cdsConfig.hpp ! src/hotspot/share/cds/cds_globals.hpp ! src/hotspot/share/cds/cppVtables.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/code/SCCache.cpp ! src/hotspot/share/code/SCCache.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/memory/allocation.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/oops/trainingData.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/init.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp

1 0

git: openjdk/leyden: premain: Rework MTD caching
by duke 05 Feb '25

05 Feb '25

Changeset: 01aa0973 Branch: premain Author: Igor Veresov <igor.veresov(a)oracle.com> Date: 2025-02-04 23:03:26 +0000 URL: https://git.openjdk.org/leyden/commit/01aa0973d4b1051dc592c96e17f86fc068137… Rework MTD caching ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/methodCounters.cpp ! src/hotspot/share/oops/methodCounters.hpp ! src/hotspot/share/oops/trainingData.cpp

1 0

Add static-jdk build in GHA
by Jiangli Zhou 04 Feb '25

04 Feb '25

With the current state of JDK mainline for static JDK support, it's a good time to add 'static-jdk' build as a minimum/initial pre-integration check in GHA. It helps catch regressions accidentally introduced in any new changes that could break the static JDK build (e.g. duplicate symbols in different JDK native libraries). We have also discussed this topic during the on-going hermetic Java zoom meetings with Ron, Alan, Magnus and others. As a starting point, we can add release and fastdebug static-jdk builds on linux-x64 for now, and then expand to other platforms when appropriate. Here are some measurements that I collected from building jdk-image and static-jdk-image for release and fastdebug binaries on my local linux x64 machine (with gcc as the default). For release build, building jdk-image and static-jdk-image takes about the same real time. For fastdebug, building a static-jdk-image takes ~1m more than building a jdk-image on my linux machine. Thoughts and additional suggestions are welcome! Clean builds ========== jdk-image: ---------------- release: real 2m20.327s fastdebug: real 3m0.262s static-jdk-image: ---------------------- release: real 2m51.024s fastdebug: real 4m11.928s Best, Jiangli

1 0

RFR: 8348960: [leyden] compiler/c1/TestConcurrentPatching.java is stuck
by Aleksey Shipilev 04 Feb '25

04 Feb '25

This is seen in GHA, and reproduces well on my machine as well: $ CONF=linux-x86_64-server-fastdebug make images test TEST=compiler/c1/TestConcurrentPatching.java <stuck, timeout> Test runs with `-Xcomp`. gdb "thread apply all bt" shows the compilers are idle. Supplying `-XX:-UseLockFreeCompileQueues` makes the test pass. I believe there is a bug in `UseLockFreeCompileQueues` in leyden repo. The comment hopefully explains what happens here. This is a corner case that seems to reproduce on the test that runs `-Xcomp` with a very few compilations. Additional testing: - [ ] GHA - [ ] Linux x86_64 server fastdebug, `compiler/c1/TestConcurrentPatching.java`, 100x ------------- Commit messages: - No iffs, no butts - Fix Changes: https://git.openjdk.org/leyden/pull/30/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=30&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348960 Stats: 20 lines in 1 file changed: 18 ins; 0 del; 2 mod Patch: https://git.openjdk.org/leyden/pull/30.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/30/head:pull/30 PR: https://git.openjdk.org/leyden/pull/30

4 21

git: openjdk/leyden: premain: 8348960: [leyden] compiler/c1/TestConcurrentPatching.java is stuck
by Vladimir Kozlov 04 Feb '25

04 Feb '25

Changeset: 59ef37a4 Branch: premain Author: Aleksey Shipilev <shade(a)openjdk.org> Committer: Vladimir Kozlov <kvn(a)openjdk.org> Date: 2025-02-04 18:08:25 +0000 URL: https://git.openjdk.org/leyden/commit/59ef37a46afa55a96196780e6b3606bd67a1c… 8348960: [leyden] compiler/c1/TestConcurrentPatching.java is stuck Reviewed-by: adinn, vlivanov ! src/hotspot/share/compiler/compileBroker.cpp

1 0

Jtreg tests with JNI native code on static JDK
by Jiangli Zhou 04 Feb '25

04 Feb '25

With the recently enhancements in JDK mainline (thanks for all contributions to the related work), it's able to build a static-jdk image (support a static-jdk/bin/java launcher executable statically linked with JDK/hotspot native), and able to execute jtreg tests on the static-jdk image. While the JDK mainline is reaching this milestone, I think it would be good to start a conversation to seed the brainstorm on jtreg testing on static-jdk image, specifically for tests with JNI natives. For jtreg tests with native, the native code has normally been linked into shared libraries. JEPS 178 <https://openjdk.org/jeps/178> enhanced JNI specification to support statically linked native libraries. As a result, we could build the jtreg test native code into static libraries and link those with the static-jdk/bin/java launcher. An obvious alternative is to continue building the jtreg test native code in shared libraries for testing on static-jdk images. The alternative is feasible (the current leyden/tree/hermetic-java-runtime <https://github.com/openjdk/leyden/tree/hermetic-java-runtime> branch can be used to demonstrate this capability). It's probably also a less disruptive solution for running jtreg tests on static JDK using today's existing testing framework/setup. There are some pre-existing assumptions about dynamic loading and linking native libraries in the tests (we have addressed and resolved many of those in JDK and VM in JDK mainline already). For both approaches described in above paragraph, we would need to remove these assumptions from the jtreg tests regardless which approach is used for building/packaging the test native code. Would be great to see this brief writeup brings in more thoughts and discussions on the Jtreg testing strategy on static JDK. Thanks! Best, Jiangli

3 4

Sketched breakdown of task for implementing code save/restore in Leyden repo and mainline
by Andrew Dinn 01 Feb '25

01 Feb '25

Hi all, Following up on our discussion in yesterday's meeting I have sketched below a list of the various tasks we need to perform to implement code save/restore, both immediately with the hope of getting them into jdk25 and in the longer term. The list includes some things it would be preferable to prototype in the Leyden premain branch before transferring to mainline, other migration tasks that serve to transfer existing protptype code from premain to mainline and more speculative tasks that are unlikely to be achievable for jdk25. Please review and feel free to offer additions and corrections -- I am not at all sure I have it all down and/or correct. n.b. one general note that applies to all migration or direct, mainline implementation tasks is that we need to consider how we handle CPUs other than aarch64/x86_64 and OSes other than Linux. Even if we leave AOT code cache functionality 'unimplemented' for other ports we will still need to ensure that the code we migrate will successfully allow for missing ('not yet available') implementations. When performing the migration tasks we may well want/need to pull in devs from those other ports to, at least, help achieve that minimum goal or, perhaps, implement some subset of the relevant functionality. regards, Andrew Dinn ----------- Leyden repo preliminaries: -------------------------- Modify SCCache implementation to save/restore code in the AOT cache file with metadata, heap data etc. Complete save/restore of i2c2i adapters and associated index Complete direct install of mapped AOT adapter code into CodeCache Complete direct install of nmethod code into CodeCache Rework save/restore of runtime, c1, opto and stubgen blobs & stubs after merge of mainline stub cleanup Implement save/restore of other demand-generated linkage stubs (i/vtable adapters, method handle adapters, ICCache, ???) Migration steps: ---------------- Migrate SCCache support to save/restore i2c2i adapters and associated lookup tables and relink methods with correct adapters Incrementally extend SCCache to support save/restore of other demand-geerated adapters and associated lookup tables Implement save/restore of runtime, c1, opto and stubgen blobs & stubs Implement save/restore of special case nmethods and associated index info (i.e. compiled MethodHandle adapter nmethods associated with Java MethodTypes and associated Java lookup table -- any others) Implement save/restore of general nmethods Implement prelinking of nmethod -> nmethod call sites Implement prelinking of nmethod -> stub call sites More speculative improvements: ------------------------------ (do we prototype these in premain before migrating?) Adjust code generation to store runtime addresses in nmethod constant section and use pc-relative loads (minimizing relocs) -- requires new relocs for gloal addresses and/or extending CDS link patching to include extra 'code address' pass. Investigate further use of 'code cache' global constant section instead of per nmethod constant sections. Investigate use of compressed nmethod 'debug info' to minimize size of AOT cache (n.b. best to use it compressed in mainline with or without AOT so save/restore gets it for free)

3 2