April 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

RFR: Prototype AOTMXBean
by Mat Carter 08 May '25

08 May '25

/** * Returns the string representing the current AOT mode of * operation. * * @return the string representing the current AOT mode. */ public String getMode(); /** * Tests if a recording is in progress. * * @return {@code true} if a recording is in progress; {@code false} otherwise. */ public boolean isRecording(); /** * If a recording is in progress or has been completed, then returns the duration in milliseconds * * @return duration of the recording in milliseconds. */ public long getRecordingDuration(); /** * If a recording is in progress, then stops the recording. * * @return {@code true} if a recording was stopped; {@code false} otherwise. */ public boolean endRecording(); ------------- Commit messages: - Add AOTMXBean test - Prototype AOTMXBean Changes: https://git.openjdk.org/leyden/pull/52/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=52&range=00 Stats: 499 lines in 13 files changed: 497 ins; 0 del; 2 mod Patch: https://git.openjdk.org/leyden/pull/52.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/52/head:pull/52 PR: https://git.openjdk.org/leyden/pull/52

6 24

RFR: Cleaner GHA build of hermetic-java-runtime branch
by Severin Gehwolf 06 May '25

06 May '25

Please review this simple PR which fixes build issues seen on GHA. Before this PR we see build failures in various Linux cross-builds and windows builds. This PR should fix those. Note: There are still GHA test failures, but at least we can build the branch on the main 3 platforms. Thoughts? ------------- Commit messages: - Cleaner GHA build of hermetic-java-runtime branch Changes: https://git.openjdk.org/leyden/pull/63/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=63&range=00 Stats: 17 lines in 4 files changed: 7 ins; 4 del; 6 mod Patch: https://git.openjdk.org/leyden/pull/63.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/63/head:pull/63 PR: https://git.openjdk.org/leyden/pull/63

3 13

RFR: 8355915: [leyden] Crash in MDO clearing the unloaded array type
by Aleksey Shipilev 01 May '25

01 May '25

Caught this when doing benchmarks with Spring Boot. See the bug for reproducer. The fix does similar thing to `is_excluded` and other code. When we encounter the `T[]`, we ask if its bottom component classes is not yet initialized. This fits nicely with our current uses, which skip such classes, and ever touch their (potentially nullptr) CLDs. Additional testing: - [x] Ad-hoc testing with most recent spring-boot-petclinic - [x] Linux x86_64 server fastdebug, `runtime/cds` ------------- Commit messages: - Fix - Fix Changes: https://git.openjdk.org/leyden/pull/64/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=64&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355915 Stats: 15 lines in 1 file changed: 11 ins; 0 del; 4 mod Patch: https://git.openjdk.org/leyden/pull/64.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/64/head:pull/64 PR: https://git.openjdk.org/leyden/pull/64

3 15

git: openjdk/leyden: premain: Fix flags behavior
by duke 30 Apr '25

30 Apr '25

Changeset: 78a59ef3 Branch: premain Author: Igor Veresov <igor.veresov(a)oracle.com> Date: 2025-04-30 15:55:50 +0000 URL: https://git.openjdk.org/leyden/commit/78a59ef3009b1948e898a851cfeb73aefb8ad… Fix flags behavior ! src/hotspot/share/cds/cdsConfig.cpp ! src/hotspot/share/oops/trainingData.hpp

1 0

git: openjdk/leyden: premain: Fix log tags
by duke 30 Apr '25

30 Apr '25

Changeset: 65bd39b6 Branch: premain Author: Igor Veresov <igor.veresov(a)oracle.com> Date: 2025-04-30 14:10:04 +0000 URL: https://git.openjdk.org/leyden/commit/65bd39b6f02ed371227bd50e72982868160b8… Fix log tags ! src/hotspot/share/oops/methodCounters.cpp ! src/hotspot/share/oops/methodData.cpp ! src/hotspot/share/oops/trainingData.cpp

1 0

New candidate JEP: 514: Ahead-of-Time Command-Line Ergonomics
by Mark Reinhold 30 Apr '25

30 Apr '25

https://openjdk.org/jeps/514 Summary: Make it easier to create ahead-of-time caches, which accelerate the startup of Java applications, by simplifying the commands required for common use cases. - Mark

1 0

git: openjdk/leyden: premain: Address review comments part 2
by duke 30 Apr '25

30 Apr '25

Changeset: a77cc17c Branch: premain Author: Igor Veresov <igor.veresov(a)oracle.com> Date: 2025-04-29 22:34:56 +0000 URL: https://git.openjdk.org/leyden/commit/a77cc17caa039a862b62cd64c67e35e666b66… Address review comments part 2 ! src/hotspot/share/ci/ciMethodData.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/memory/allocation.cpp ! src/hotspot/share/memory/allocation.hpp ! test/hotspot/jtreg/runtime/cds/appcds/aotProfile/AOTProfileFlags.java

1 0

issue and crash when testing premain on a real world large app
by Olivier Bourgain 29 Apr '25

29 Apr '25

Hello, I tested the premain branch on a pretty large Spring Boot application (>1M loc, fat jar is about 240MB) and had two issues. First issue is similar to my previous issue https://mail.openjdk.org/pipermail/leyden-dev/2025-April/001875.html, I had to set -XX:-ArchiveLoaderLookupCache to avoid Leyden failing due to a large ConcurrentHashMap's backing array. Second issue is way worse, I had a segfault on application start. I tracked down the issue to: - use the Bouncy Castle security provider - run as a Spring Boot app. I created a reproducer there https://github.com/obourgain/leyden-crash I couldn't reproduce as a simple main, but it should be possible to reduce the size of the reproducer even more. Some observations: - During the aotconf creation, bouncy castle classes are excluded because they are from a signed jar like: Skipping org/bouncycastle/jcajce/provider/asymmetric/util/BaseKeyFactorySpi: Signed JAR - During the AOT cache creation there are a lot of warnings , it may be related to the crash: [1,064s][warning][cds,heap] Archive heap points to a static field that may hold a different value at runtime: [1,064s][warning][cds,heap] Field: sun/security/x509/AlgorithmId::SHA3_512withRSA_oid [1,064s][warning][cds,heap] Value: sun.security.util.ObjectIdentifier [1,064s][warning][cds,heap] {0x00000006000453b8} - klass: 'sun/security/util/ObjectIdentifier' - flags: [1,064s][warning][cds,heap] [1,064s][warning][cds,heap] - ---- fields (total size 4 words): [1,064s][warning][cds,heap] - private 'componentLen' 'I' @12 -1 (0xffffffff) [1,064s][warning][cds,heap] - private transient 'componentsCalculated' 'Z' @16 false (0x00) [1,064s][warning][cds,heap] - private 'encoding' '[B' @20 [B{0x00000006000453d8} (0xc0008a7b) [1,064s][warning][cds,heap] - private volatile transient 'stringForm' 'Ljava/lang/String;' @24 "2.16.840.1.101.3.4.3.16"{0x0000000600045378} (0xc0008a6f) [1,064s][warning][cds,heap] - private 'components' 'Ljava/lang/Object;' @28 null (0x00000000) [1,064s][warning][cds,heap] --- trace begin --- [1,064s][warning][cds,heap] [ 0] {0x0000000600043330} java.util.concurrent.ConcurrentHashMap::table (offset = 20) [1,064s][warning][cds,heap] [ 1] {0x0000000600043370} [Ljava.util.concurrent.ConcurrentHashMap$Node; @[87] [1,064s][warning][cds,heap] [ 2] {0x0000000600045358} java.util.concurrent.ConcurrentHashMap$Node::val (offset = 20) [1,064s][warning][cds,heap] [ 3] {0x00000006000453b8} sun.security.util.ObjectIdentifier [1,064s][warning][cds,heap] --- trace end --- - Sample Backtrace from the segfault: 💣 Program crashed: Bad pointer dereference at 0x0000000000000000 Thread 2 crashed: 0 0x0000000000000000 1 0x00000001132b5230 2 0x00000001132b0154 3 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 988 in libjvm.dylib at make/hotspot/src/hotspot/share/runtime/javaCalls.cpp:415:7 4 InstanceKlass::call_class_initializer(JavaThread*) + 764 in libjvm.dylib at make/hotspot/src/hotspot/share/oops/instanceKlass.cpp:1777:5 5 InstanceKlass::initialize_impl(JavaThread*) + 2748 in libjvm.dylib at make/hotspot/src/hotspot/share/oops/instanceKlass.cpp:1331:7 6 InstanceKlass::initialize_impl(JavaThread*) + 1540 in libjvm.dylib at make/hotspot/src/hotspot/share/oops/instanceKlass.cpp:1292:20 7 HeapShared::resolve_or_init_classes_for_subgraph_of(Klass*, bool, JavaThread*) + 900 in libjvm.dylib at make/hotspot/src/hotspot/share/cds/heapShared.cpp:1491:9 8 HeapShared::initialize_from_archived_subgraph(JavaThread*, Klass*) + 336 in libjvm.dylib at make/hotspot/src/hotspot/share/cds/heapShared.cpp:1415:5 9 JVM_InitializeFromArchive + 560 in libjvm.dylib at make/hotspot/src/hotspot/share/prims/jvm.cpp:3369:3 10 0x00000001132b8e80 11 0x00000001132b4a90 12 0x00000001132b0154 13 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 988 in libjvm.dylib at make/hotspot/src/hotspot/share/runtime/javaCalls.cpp:415:7 14 InstanceKlass::call_class_initializer(JavaThread*) + 764 in libjvm.dylib at make/hotspot/src/hotspot/share/oops/instanceKlass.cpp:1777:5 15 InstanceKlass::initialize_impl(JavaThread*) + 2748 in libjvm.dylib at make/hotspot/src/hotspot/share/oops/instanceKlass.cpp:1331:7 16 LinkResolver::resolve_static_call(CallInfo&, LinkInfo const&, bool, JavaThread*) + 152 in libjvm.dylib at make/hotspot/src/hotspot/share/interpreter/linkResolver.cpp:1116:21 17 LinkResolver::resolve_invokestatic(CallInfo&, constantPoolHandle const&, int, JavaThread*) + 52 in libjvm.dylib at make/hotspot/src/hotspot/share/interpreter/linkResolver.cpp:1749:3 18 LinkResolver::resolve_invoke(CallInfo&, Handle, constantPoolHandle const&, int, Bytecodes::Code, JavaThread*) + 116 in libjvm.dylib at make/hotspot/src/hotspot/share/interpreter/linkResolver.cpp:1708:39 19 InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code) + 748 in libjvm.dylib at make/hotspot/src/hotspot/share/interpreter/interpreterRuntime.cpp:988:5 20 InterpreterRuntime::resolve_invokestatic(JavaThread*) + 420 in libjvm.dylib at make/hotspot/src/hotspot/share/interpreter/interpreterRuntime.cpp:952:3 21 InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code) + 2644 in libjvm.dylib at make/hotspot/src/hotspot/share/interpreter/interpreterRuntime.cpp:1167:37 22 0x00000001132c48c4 23 0x00000001132b0154 24 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 988 in libjvm.dylib at make/hotspot/src/hotspot/share/runtime/javaCalls.cpp:415:7 25 InstanceKlass::call_class_initializer(JavaThread*) + 764 in libjvm.dylib at make/hotspot/src/hotspot/share/oops/instanceKlass.cpp:1777:5 26 InstanceKlass::initialize_impl(JavaThread*) + 2748 in libjvm.dylib at make/hotspot/src/hotspot/share/oops/instanceKlass.cpp:1331:7 27 InstanceKlass::initialize_impl(JavaThread*) + 1540 in libjvm.dylib at make/hotspot/src/hotspot/share/oops/instanceKlass.cpp:1292:20 28 HeapShared::init_classes_for_special_subgraph(Handle, JavaThread*) + 356 in libjvm.dylib at make/hotspot/src/hotspot/share/cds/heapShared.cpp:1387:13 29 Threads::create_vm(JavaVMInitArgs*, bool*) + 1504 in libjvm.dylib at make/hotspot/src/hotspot/share/runtime/threads.cpp:808:5 30 JNI_CreateJavaVM_inner(JavaVM_**, void**, void*) + 80 in libjvm.dylib at make/hotspot/src/hotspot/share/prims/jni.cpp:3587:12 31 JNI_CreateJavaVM + 116 in libjvm.dylib at make/hotspot/src/hotspot/share/prims/jni.cpp:3678:14 32 InitializeJVM + 184 in libjli.dylib at make/src/java.base/share/native/libjli/java.c:1510:9 33 JavaMain + 256 in libjli.dylib at make/src/java.base/share/native/libjli/java.c:494:10 34 ThreadJavaMain + 12 in libjli.dylib at make/src/java.base/macosx/native/libjli/java_md_macosx.m:679:29 35 0x0000000197d71c0c _pthread_start + 136 in libsystem_pthread.dylib With regards to performance, with disabling the loading of BouncyCastleProvider in the application, it starts way faster and with lower resources, impressive work. - baseline (extracted Spring Boot jar) Time (mean ± σ): 11.510 s ± 0.432 s [User: 32.354 s, System: 1.751 s] - Leyden main branch Time (mean ± σ): 6.031 s ± 0.090 s [User: 12.591 s, System: 0.513 s] aotcache file = 250 MB - Leyden premain branch Time (mean ± σ): 4.801 s ± 0.022 s [User: 6.662 s, System: 0.390 s] aotcache file = 300 MB Regards.

3 4