March 2025 - leyden-dev

Questions about the Hermetic Java project
by Magnus Ihse Bursie 09 Jun '25

09 Jun '25

First some background for build-dev: I have spent some time looking at the build implications of the Hermetic Java effort, which is part of Project Leyden. A high-level overview is available here: https://cr.openjdk.org/~jiangli/hermetic_java.pdf and the current source code is here: https://github.com/openjdk/leyden/tree/hermetic-java-runtime. Hermetic Java faces several challenges, but the part that is relevant for the build system is the ability to create static libraries. We've had this functionality (in three different ways...) for some time, but it is rather badly implemented. As a result of my investigations, I have a bunch of questions. :-) I have gotten some answers in private discussion, but for the sake of transparency I will repeat them here, to foster an open dialogue. 1. Am I correct in understanding that the ultimate goal of this exercise is to be able to have jmods which include static libraries (*.a) of the native code which the module uses, and that the user can then run a special jlink command to have this linked into a single executable binary (which also bundles the *.class files and any additional resources needed)? 2. If so, is the idea to create special kinds of static jmods, like java.base-static.jmod, that contains *.a files instead of lib*.so files? Or is the idea that the normal jmod should contain both? 3. Linking .o and .a files into an executable is a formidable task. Is the intention to have jlink call a system-provided ld, or to bundle ld with jlink, or to reimplement this functionality in Java? 4. Is the intention is to allow users to create their own jmods with static libraries, and have these linked in as well? This seems to be the case. If that is so, then there will always be the risk for name collisions, and we can only minimize the risk by making sure any global names are as unique as possible. 5. The original implementation of static builds in the JDK, created for the Mobile project, used a configure flag, --enable-static-builds, to change the entire behavior of the build system to only produce *.a files instead of lib*.so. In contrast, the current system is using a special target instead. In my eyes, this is a much worse solution. Apart from the conceptual principle (if the build should generate static or dynamic libraries is definitely a property of what a "configuration" means), this makes it much harder to implement efficiently, since we cannot make changes in NativeCompilation.gmk, where they are needed. That was not as much a question as a statement. 🙂 But here is the question: Do you think it would be reasonable to restore the old behavior but with the new methods, so that we don't use special targets, but instead tells configure to generate static libraries? I'm thinking we should have a flag like "--with-library-type=" that can have values "dynamic" (which is default), "static" or "both". I am not sure if "both" are needed, but if we want to bundle both lib*.so and *.a files into a single jmod file (see question 2 above), then it definitely is. In general, the cost of producing two kinds of libraries are quite small, compared to the cost of compiling the source code to object files. Finally, I have looked at how to manipulate symbol visibility. There seems many ways forward, so I feel confident that we can find a good solution. One way forward is to use objcopy to manipulate symbol status (global/local). There is an option --localize-symbol in objcopy, that has been available in objcopy since at least 2.15, which was released 2004, so it should be safe to use. But ideally we should avoid using objcopy and do this as part of the linking process. This should be possible to do, given that we make changes in NativeCompilation.gmk -- see question 5 above. As a fallback, it is also possible to rename symbols, either piecewise or wholesale, using objcopy. There are many ways to do this, using --prefix-symbols, --redefine-sym or --redefine-syms (note the -s, this takes a file with a list of symbols). Thus we can always introduce a "post factum namespace" by renaming symbols. So in the end, I think it will be fully possible to produce .a files that only has global symbols for the functions that are part of the API exposed by that library, and have all other symbols local, and make this is in a way that is consistent with the rest of the build system. Finally, a note on Hotspot. Due to debugging reasons, we export basically all symbols in hotspot as global. This is not reasonable to do for a static build. The effect of not exporting those symbols will be that SA will not function to 100%. On the other hand, I have no idea if SA works at all with a static build. Have you tested this? Is this part of the plan to support, or will it be officially dropped for Hermetic Java? /Magnus

7 38

RFR: 8347755: Support static library in jmod
by Henry Jen 19 May '25

19 May '25

This PR add --static-libs option to the jmod tool, it's basically mirroring --libs option to support adding a new section of static archive into the jmod file under the new section `static-lib`. The JMOD magic header contains a MAJOR and MINOR version, we bump up the MINOR version if the --static-libs option is specified; otherwise, keep the MINOR version as 1. This allow created JMOD file without the newly supported static-lib section to continue be consumed by earlier version of jmod tool. Also fix the formatting for _hermetic_jdk_jimage_offset, which is a julong(uint64_t) as unsigned long long on MacOS, thus need to use %llu. ------------- Commit messages: - Fix julong format on MacOS - Add --static-libs to jmod Changes: https://git.openjdk.org/leyden/pull/46/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=46&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347755 Stats: 95 lines in 6 files changed: 79 ins; 0 del; 16 mod Patch: https://git.openjdk.org/leyden/pull/46.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/46/head:pull/46 PR: https://git.openjdk.org/leyden/pull/46

7 42

NotCompliantMBeanException during cache creation
by Gunnar Morling 09 Apr '25

09 Apr '25

Hey all, I'm trying to run Apache Kafka with Project Leyden, using Java build 24+36-3646. I am following the steps laid out in JEP 483, yet when trying to create the ahead-of-time cache (via -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot), I'm getting the following exception (full stacktrace at [1]): javax.management.NotCompliantMBeanException: com.sun.management.UnixOperatingSystemMXBean: During -Xshare:dump, module system cannot be modified after it's initialized Is there any way to analyse that problem, e.g. to identify the MBean in question? Thanks for any pointers, --Gunnar [1] https://gist.github.com/gunnarmorling/264bfde458c71152336be6faab115563

5 7

RFR: 8349814: [leyden] Avoid uncommon traps in preload code
by Aleksey Shipilev 02 Apr '25

02 Apr '25

Preload code is the C2 code we load very early, before it gets substituted by more advanced C2 code. We are seeing lots of uncommon traps from the preloaded code, though, which invalidates it too early. We can do precompile code without uncommon traps to alleviate this. Additional testing: - [x] Ad-hoc perf tests (see comment below) - [x] Linux x86_64 server fastdebug, `runtime/cds` ------------- Commit messages: - Fix Changes: https://git.openjdk.org/leyden/pull/38/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=38&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349814 Stats: 19 lines in 3 files changed: 18 ins; 0 del; 1 mod Patch: https://git.openjdk.org/leyden/pull/38.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/38/head:pull/38 PR: https://git.openjdk.org/leyden/pull/38

4 30

RFR: 8351965: [leyden] Skip installing C2 AOT code if C2 precompiled AOT code trapped
by Aleksey Shipilev 02 Apr '25

02 Apr '25

This is clearly visible in compilation logs: 43 W0.1 Q8.1 C0.0 293 AP 4 com.sun.tools.javac.util.StringNameTable::fromString (50 bytes) [0.049s][debug ][deoptimization] cid= 293 level=4 com.sun.tools.javac.util.StringNameTable::fromString(Ljava/lang/String;)Lcom/sun/tools/javac/util/Name; trap_bci=28 unloaded reinterpret pc=0x00007c6bd7e4e7ac relative_pc=0x000000000000068c 49 293 AP 4 com.sun.tools.javac.util.StringNameTable::fromString (50 bytes) made not entrant 49 W0.2 Q0.0 C0.3 1394 2 com.sun.tools.javac.util.StringNameTable::fromString (50 bytes) 90 1394 2 com.sun.tools.javac.util.StringNameTable::fromString (50 bytes) made not entrant 90 W0.0 Q0.0 C0.1 1867 A 4 com.sun.tools.javac.util.StringNameTable::fromString (50 bytes) [0.098s][debug ][deoptimization] cid=1867 level=4 com.sun.tools.javac.util.StringNameTable::fromString(Ljava/lang/String;)Lcom/sun/tools/javac/util/Name; trap_bci=28 unloaded reinterpret pc=0x00007c6bd7ebcb58 relative_pc=0x00000000000005d8 98 1867 A 4 com.sun.tools.javac.util.StringNameTable::fromString (50 bytes) made not entrant 104 W0.0 Q0.0 C0.3 1942 2 com.sun.tools.javac.util.StringNameTable::fromString (50 bytes) 130 1942 2 com.sun.tools.javac.util.StringNameTable::fromString (50 bytes) made not entrant 130 W1.0 Q0.7 C13.3 1968 4 com.sun.tools.javac.util.StringNameTable::fromString (50 bytes) So the AP4 method was preloaded, then it trapped and got replaced by T2 method, which eventually got to C2, at which point we loaded A4 method. That method trapped _at the same bci_, which is really expected, so we are back at T2, then then to real T4. So we have spent one deopt cycle unnecessarily, and the code was in T2 for twice as long. I don't think we would be able to fully tame uncommon traps from the preload code, so fixing this gap is valuable. `decompile_count()` is only updated by C2, so we can just check it directly. Additional testing: - [x] Ad-hoc benchmarks - [x] Linux x86_64 server fastdebug, `runtime/cds` ------------- Commit messages: - Cleanup - Fix Changes: https://git.openjdk.org/leyden/pull/48/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=48&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351965 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/leyden/pull/48.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/48/head:pull/48 PR: https://git.openjdk.org/leyden/pull/48

3 33

git: openjdk/leyden: premain: Remove MethodData::__gap
by duke 31 Mar '25

31 Mar '25

Changeset: 3613cb65 Branch: premain Author: Igor Veresov <igor.veresov(a)oracle.com> Date: 2025-03-31 15:13:08 +0000 URL: https://git.openjdk.org/leyden/commit/3613cb6524d27f4ceec3f045245fe2b610ad9… Remove MethodData::__gap ! src/hotspot/share/oops/methodData.hpp

1 0

git: openjdk/leyden: premain: Cleaned up log message with pointers that are set to null by RelocateEmbeddedPointers
by Ioi Lam 31 Mar '25

31 Mar '25

Changeset: 334471da Branch: premain Author: Ioi Lam <iklam(a)openjdk.org> Date: 2025-03-31 08:11:04 +0000 URL: https://git.openjdk.org/leyden/commit/334471da3ea3c0071ae305c8c1ff2be6dd34f… Cleaned up log message with pointers that are set to null by RelocateEmbeddedPointers ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveBuilder.hpp

1 0

RFR: Save/load nmethod without going through CodeBuffer
by Ashutosh Mehra 31 Mar '25

31 Mar '25

This is the prototype for storing and loading nmethods without going through the CodeBuffer. The new implementation is protected by the flag -XX:+UseNewCode2. Some numbers using this implementation: spring-boot-getting-started [0] shows startup improvement of ~ 7.5%% and quarkus-getting-started [1] shows improvement of around ~3.5%. Numbers for Springboot Old build = /home/asmehra/data/ashu-mehra/leyden/build/nmethod-single-copy-load-release/images/jdk with options -XX:+UnlockDiagnosticVMOptions -XX:-UseNewCode2 New build = /home/asmehra/data/ashu-mehra/leyden/build/nmethod-single-copy-load-release/images/jdk with options -XX:+UnlockDiagnosticVMOptions -XX:+UseNewCode2 Run,Old CDS + AOT,New CDS + AOT 1,544,512 2,554,525 3,550,508 4,571,515 5,550,506 6,552,515 7,568,510 8,554,517 9,551,506 10,556,508 Geomean,554.94,512.17 Stdev,7.90,5.65 Numbers for Quarkus: Old build = /home/asmehra/data/ashu-mehra/leyden/build/nmethod-single-copy-load-release/images/jdk with options -XX:+UnlockDiagnosticVMOptions -XX:-UseNewCode2 New build = /home/asmehra/data/ashu-mehra/leyden/build/nmethod-single-copy-load-release/images/jdk with options -XX:+UnlockDiagnosticVMOptions -XX:+UseNewCode2 Run,Old CDS + AOT,New CDS + AOT 1,359,346 2,360,353 3,373,357 4,376,356 5,366,353 6,360,356 7,361,361 8,347,349 9,355,336 10,374,342 Geomean,363.00,350.82 Stdev,8.70,7.27 -Xlog:init logs the load time from AOT code cache at JVM exit. For spring-boot-getting-started without `UseNewCode2`: [3.459s][info][init] SC Load Time: 0.202 s [3.459s][info][init] nmethod register: 0.135 s [3.459s][info][init] find cached code: 0.007 s For spring-boot-getting-started with `UseNewCode2`: [3.192s][info][init] [3.192s][info][init] SC Load Time: 0.138 s [3.192s][info][init] nmethod register: 0.111 s [3.192s][info][init] find cached code: 0.006 s For quarkus-getting-started without `UseNewCode2` [0.392s][info][init] SC Load Time: 0.060 s [0.392s][info][init] nmethod register: 0.039 s [0.392s][info][init] find cached code: 0.002 s For quarkus-getting-started with `UseNewCode2` [0.386s][info][init] SC Load Time: 0.033 s [0.386s][info][init] nmethod register: 0.027 s [0.386s][info][init] find cached code: 0.002 s [0] https://github.com/openjdk/leyden/tree/premain/test/hotspot/jtreg/premain/s… [1] https://github.com/openjdk/leyden/tree/premain/test/hotspot/jtreg/premain/q… ------------- Commit messages: - Handle mutable nmethod data properly when storing/loading from AOT code - Fix win compile failures - Remove trailing whitespaces - Include os.hpp to fix compile failures - Store asm remarks and debug strings in the cache - More whitespace fixes - Fix whitespace errors; Some more cleanup - Fix compile failures in minimal build - Removed old code for storing/loading nmethods from AOT code cache - Store nmethod directly into AOT code cache - ... and 1 more: https://git.openjdk.org/leyden/compare/f57ae6a4...04b77eab Changes: https://git.openjdk.org/leyden/pull/27/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=27&range=00 Stats: 1765 lines in 16 files changed: 1119 ins; 430 del; 216 mod Patch: https://git.openjdk.org/leyden/pull/27.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/27/head:pull/27 PR: https://git.openjdk.org/leyden/pull/27

4 28

git: openjdk/leyden: premain: Save/load nmethod without going through CodeBuffer
by Ashutosh Mehra 31 Mar '25

31 Mar '25

Changeset: b55a514d Branch: premain Author: Ashutosh Mehra <asmehra(a)openjdk.org> Date: 2025-03-31 08:37:24 +0000 URL: https://git.openjdk.org/leyden/commit/b55a514d22f82b5283af480e6a958a2e4f9d0… Save/load nmethod without going through CodeBuffer Reviewed-by: adinn, kvn ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/asm/codeBuffer.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/code/SCCache.cpp ! src/hotspot/share/code/SCCache.hpp ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/code/relocInfo.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileTask.cpp ! src/hotspot/share/compiler/compileTask.hpp ! src/hotspot/share/compiler/oopMap.hpp

1 0

git: openjdk/leyden: premain: Backport some of the JEP2 review changes
by duke 29 Mar '25

29 Mar '25

Changeset: 2c2289b1 Branch: premain Author: Igor Veresov <igor.veresov(a)oracle.com> Date: 2025-03-28 18:41:23 +0000 URL: https://git.openjdk.org/leyden/commit/2c2289b153823b747637fd603c5305888a2c1… Backport some of the JEP2 review changes ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/oops/methodCounters.hpp ! src/hotspot/share/oops/recompilationSchedule.cpp ! src/hotspot/share/oops/recompilationSchedule.hpp ! src/hotspot/share/oops/trainingData.cpp ! src/hotspot/share/oops/trainingData.hpp

1 0