July 2024 - 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

premain: Possible solutions to use runtime G1 region grain size in AOT code (JDK-8335440)
by Andrew Dinn 21 Aug '24

21 Aug '24

I have prototyped two (aarch64-specific) solutions for JDK-8335440 both of which fix the G1 write barrier in AOT code to use the runtime region grain size. Both solutions make AOT code resilient to any change in max heap between assembly and production runs. The problem arises because ergonomics uses the heap size to derive a G1 region size and the latter size determines what shift is needed to convert a store address to a card table index. In currently generated nmethod and *stub* code) the shift count is installed as an immediate operand of a generated shift instruction. In AOT code the shift counts needs to be appropriate to the current runtime region size. AOT code can resolve this requirement in two ways. It can load the shift from a well known location and supply the shift count as a register operand. Alternatively, it can employ load-time rewriting of the instruction stream to update the immediate operand. Both current solutions rely on loading rather than instruction rewriting. The first solution installs the shift count in a (byte) field added to every Java thread. It modifies barrier generation when the SCCache is open for writing to load the shift count from the thread field. This solution requires no relocation when the AOT stub/nmethod is loaded from the cache since the load is always at a fixed offset from the thread register. If the SCCache is not open for writing the count is generated as normal i.e. as an immediate operand. https://github.com/adinn/leyden/compare/premain...adinn:leyden:JDK-8335440-… The second solution modifies barrier generation when the SCCache is open for writing to load the shift count from a runtime field, G1HeapRegion::LogHRGrainSize i.e. the same field that determines the immediate count used for normal generation. In order to make this visible to the compilers and SCC address table the address of this field is exported via the card table. This solution requires the AOT code to reference the target address using a runtime address relocation. Once again, if the SCCache is not open for writing the count is generated as normal i.e. as an immediate operand. https://github.com/adinn/leyden/compare/premain...adinn:leyden:JDK-8335440-… I ran the javac benchmark with each of these solutions compared against the equivalent premain build. Neither indicated any noticeable change in execution time -- at least not within the margins of error of the test runs (which, on my M2 machine were +/- 5 msecs in a 95 msec run). A better test might be to take a long running app and see if the change to the AOT barrier code introduced any change in overall execution time. I implemented these two solutions first because neither of them requires implementing any new relocations. There are two alternatives which would require new relocations that may still be worth investigating. Option three is to mark the shift instruction with a new relocation. Patching of the relocation address would simply require regenerating it with an immediate that matches (log2 of the) current region size. The fourth option is to load the shift count from a data area associated with the current blob. In the case of an nmethod this would be the nmethod constants section. In the case of a generated stub this would have to be a dedicated memory address in its associated blob. Either way the data location would need to be marked with a new relocation. Patching of the relocation address would simply require copying the (log2 of the) current region size ito the data area. I'll hold off on adding these solutions (also on implementing the x86 versions -- well, more likely, letting Ashu provide them ;-) until I get some feedback on these first two. I'll also see if I can get any better indication of whether the performance of the first two solutions is an issue. I think solution one is by far the simplest, resolving the immediate issue with least fuss (note that I poked the necessary data byte into a hole in the thread record so it has no space implications). However, if we end up having to tweak generated code to deal with other config changes the alternatives may be worth investing in as they might scale better. regards, Andrew Dinn -----------

4 22

git: openjdk/leyden: premain-ea: Do not use decomp count for one step workflow
by duke 26 Jul '24

26 Jul '24

Changeset: c0df40cf Branch: premain-ea Author: Vladimir Kozlov <vladimir.kozlov(a)oracle.com> Date: 2024-07-26 15:12:42 +0000 URL: https://git.openjdk.org/leyden/commit/c0df40cfe099d2e64350130d80c81c301afbd… Do not use decomp count for one step workflow ! src/hotspot/share/code/SCCache.cpp

1 0

Missing entry in SCC due to decomp count mismatch
by Ashutosh Mehra 26 Jul '24

26 Jul '24

During the startup of a quarkus app, I see a particular method that gets C2 compiled almost every time in the production run with the premain branch . I don't see this happening with the mainline. The reason this method caught my attention is the significant amount of memory its C2 compilation consumes (between 25-40 mb) compared to the other compilations. The method in question is jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z The assembly phase added two entries for this method in the code cache: [3.391s][info ][scc,nmethod ] 2631 (L4): Writing nmethod 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z' (comp level: 4, decomp: 1, has clinit barriers) to Startup Code Cache 'quarkus-getting-started.cds.code' ... [7.215s][info ][scc,nmethod ] 4354 (L4): Writing nmethod 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z' (comp level: 4, decomp: 1) to Startup Code Cache 'quarkus-getting-started.cds.code' In the production run the "preload" version was successfully loaded: [0.695s][info ][scc,nmethod ] 727 (L4): Preloading nmethod 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z' (decomp: 0, hash: 0x493f24e2, has clinit barriers) The PrintTieredEvents logs indicate this method was also sent for compilation during replay training: 0.877593: [force-compile level=4 [jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z] @-1 queues=0,0 rate=0.000000 load=0.007812 k=1.00,1.00 total=56,0 mdo=0(0),0(0) max levels=4,0 compilable=c1,c1-osr,c2,c2-osr status=idle mtd: mdo=18830(8306), 0(0), deps=0] Ideally this request should have been fulfilled by the second entry in the code cache. But instead I see this message: [0.878s][info ][scc,nmethod ] Missing entry for 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z' (comp_level 4, decomp: 0, hash: 0x493f24e2) This is followed by the C2 compilation of the method. It looks like the failure to find the second entry is due to a mismatch of the decomp count [0]. The decomp count is stored in the MethodData. Is it possible that the method data is not yet installed when replay training is done? If so, is that by design or a bug? [0] https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b2… Thanks, - Ashutosh Mehra

2 6

git: openjdk/leyden: premain: Added spring-boot-getting-started demo
by duke 26 Jul '24

26 Jul '24

Changeset: d7c97f22 Branch: premain Author: iklam <ilam3388(a)gmail.com> Date: 2024-07-26 10:27:04 +0000 URL: https://git.openjdk.org/leyden/commit/d7c97f2257d329db98e42bd9a99959eefb7fb… Added spring-boot-getting-started demo ! README.md ! test/hotspot/jtreg/premain/README.md ! test/hotspot/jtreg/premain/lib/GithubMDChart.java + test/hotspot/jtreg/premain/spring-boot-getting-started/Application.java + test/hotspot/jtreg/premain/spring-boot-getting-started/Makefile + test/hotspot/jtreg/premain/spring-boot-getting-started/pom.xml

1 0

git: openjdk/leyden: premain: Fixed silly mistake in last commit
by duke 26 Jul '24

26 Jul '24

Changeset: c0826c59 Branch: premain Author: iklam <ilam3388(a)gmail.com> Date: 2024-07-25 22:14:42 +0000 URL: https://git.openjdk.org/leyden/commit/c0826c59c7d47b36660daa9b4b523e5eed1a3… Fixed silly mistake in last commit ! src/hotspot/share/cds/cdsConfig.cpp

1 0

git: openjdk/leyden: premain: Added -XX:AOTMode as specified in latest JEP draft. Removed RecordAOTConfiguration/CreateAOTCache
by duke 25 Jul '24

25 Jul '24

Changeset: f972b8dc Branch: premain Author: iklam <ilam3388(a)gmail.com> Date: 2024-07-25 15:06:08 +0000 URL: https://git.openjdk.org/leyden/commit/f972b8dcc92fb531cb8b9991676c9f1d1be05… Added -XX:AOTMode as specified in latest JEP draft. Removed RecordAOTConfiguration/CreateAOTCache ! src/hotspot/share/cds/cdsConfig.cpp ! src/hotspot/share/cds/cds_globals.hpp ! src/java.base/share/native/libjli/java.c ! test/hotspot/jtreg/runtime/cds/appcds/AOTFlags.java

1 0

git: openjdk/leyden: premain: fixed typo
by duke 24 Jul '24

24 Jul '24

Changeset: 37b332cc Branch: premain Author: iklam <ilam3388(a)gmail.com> Date: 2024-07-24 08:52:38 +0000 URL: https://git.openjdk.org/leyden/commit/37b332cc445682814c36cd482244a146faa95… fixed typo ! src/hotspot/share/cds/cds_globals.hpp

1 0

git: openjdk/leyden: premain: New "AOT" options (-XX:AOTCache=xxx, etc) implemented as aliases to existing CDS options
by duke 24 Jul '24

24 Jul '24

Changeset: b24e6fa2 Branch: premain Author: iklam <ilam3388(a)gmail.com> Date: 2024-07-24 08:47:44 +0000 URL: https://git.openjdk.org/leyden/commit/b24e6fa23528e9aadd4f4b41035c22b7db2bf… New "AOT" options (-XX:AOTCache=xxx, etc) implemented as aliases to existing CDS options ! src/hotspot/share/cds/cdsConfig.cpp ! src/hotspot/share/cds/cdsConfig.hpp ! src/hotspot/share/cds/cds_globals.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/java.base/share/native/libjli/java.c + test/hotspot/jtreg/runtime/cds/appcds/AOTFlags.java

1 0

git: openjdk/leyden: premain: Clean up cdsEnumKlass.cpp code for upstreaming to mainline
by duke 23 Jul '24

23 Jul '24

Changeset: ec5eb996 Branch: premain Author: iklam <ilam3388(a)gmail.com> Date: 2024-07-23 00:04:29 +0000 URL: https://git.openjdk.org/leyden/commit/ec5eb99653624d02a923a314ce40086753b24… Clean up cdsEnumKlass.cpp code for upstreaming to mainline ! src/hotspot/share/cds/cdsEnumKlass.cpp ! src/hotspot/share/cds/cdsEnumKlass.hpp ! src/hotspot/share/cds/heapShared.cpp ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchiveHeapTestClass.java

1 0