November 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

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-temp-merge-after-jep-483: fix build
by duke 27 Nov '24

27 Nov '24

Changeset: ba71a22b Branch: premain-temp-merge-after-jep-483 Author: Vladimir Ivanov <vladimir.x.ivanov(a)oracle.com> Date: 2024-11-27 14:24:34 +0000 URL: https://git.openjdk.org/leyden/commit/ba71a22b7764f65942fcaa4e59b0e98e0e791… fix build ! src/hotspot/cpu/x86/methodHandles_x86.cpp

1 0

git: openjdk/leyden: premain-temp-merge-after-jep-483: fix build
by duke 27 Nov '24

27 Nov '24

Changeset: 6ca0c9ef Branch: premain-temp-merge-after-jep-483 Author: Vladimir Ivanov <vladimir.x.ivanov(a)oracle.com> Date: 2024-11-27 14:23:55 +0000 URL: https://git.openjdk.org/leyden/commit/6ca0c9efcbe3f84a9c1f77be670d485e55945… fix build ! src/hotspot/cpu/x86/methodHandles_x86.cpp

1 0

git: openjdk/leyden: premain-temp-merge-after-jep-483: Don't allocate new C strings on the fly
by duke 27 Nov '24

27 Nov '24

Changeset: 58565167 Branch: premain-temp-merge-after-jep-483 Author: Vladimir Ivanov <vladimir.x.ivanov(a)oracle.com> Date: 2024-11-27 14:20:00 +0000 URL: https://git.openjdk.org/leyden/commit/58565167d5c8ba59d3034cf2ce4c249e4d7a7… Don't allocate new C strings on the fly ! src/hotspot/cpu/x86/methodHandles_x86.cpp

1 0

Premain options for triggering end of training
by Mat Carter 26 Nov '24

26 Nov '24

The following three options have been integrated into premain to assist with the recording of training data. What parts make it to tip (and in what format) will be based on feedback from training workflows as developers explore Leyden. Command line option: -XX:AOTEndTrainingOnMethodEntry=[methods][,count] - methods: comma separated list of methods specified in a similar manner to -XX:CompileOnly - count: trigger end of training after ‘count’ tracked methods invoked (total, not per method) JCmd option: jcmd AOT.end_training - ends training API option (don’t panic: System was simply the easiest point to integrate support for experimentation): void System.AOTEndTraining() bool System.AOTIsTraining() - returns true if a training run and the recording of training data has not yet stopped Ending training does not terminate the application; it simply stops recording and dumps out the data for creating the AOT cache. If none of the methods are used (or the ‘count’ was not met) then the application will stop recording data when the application terminates. This work is based on the enhancement request in JBS [1]; the PR is [2] and commit is [3] Cheers Mat [1] https://bugs.openjdk.org/browse/JDK-8335358 [2] https://github.com/openjdk/leyden/pull/21#issuecomment-2495140178 [3] https://github.com/openjdk/leyden/commit/6e6030b917f1dfcd4ea7c6207ce0626bf5…

1 0

RFR: 8335358 - alternative ways to trigger the end of training run
by Mat Carter 23 Nov '24

23 Nov '24

AOT training can be ended using either - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly] - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42 - jcmd AOT.end_training supports arm64 and x64 note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process) JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358 ------------- Commit messages: - whitespace fixes - For c1 and c2 we add the trigger test at code gen, interpreter cant do this as method_entry are shared. - Consistant naming and remove debug code - the core trigger method should not be counted, but the compiled code call it indirectly predicated by the counter. This is so that jcmd works and is NOT predicated on any counter value - Added optional count parameter - ignore AOTCreateOnMethodEntry when CDSPreimage is specified - fixed patch merge issue - added support for x86 - fixed c1 and c2 issues - fixed patch issues - ... and 6 more: https://git.openjdk.org/leyden/compare/cf036d70...ad3d6f18 Changes: https://git.openjdk.org/leyden/pull/21/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335358 Stats: 277 lines in 28 files changed: 260 ins; 0 del; 17 mod Patch: https://git.openjdk.org/leyden/pull/21.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/21/head:pull/21 PR: https://git.openjdk.org/leyden/pull/21

6 49

git: openjdk/leyden: premain: 8335358: [premain] Explore alternative ways to trigger the end of training run
by Ioi Lam 23 Nov '24

23 Nov '24

Changeset: 6e6030b9 Branch: premain Author: Mat Carter <macarte(a)openjdk.org> Committer: Ioi Lam <iklam(a)openjdk.org> Date: 2024-11-23 00:23:36 +0000 URL: https://git.openjdk.org/leyden/commit/6e6030b917f1dfcd4ea7c6207ce0626bf5452… 8335358: [premain] Explore alternative ways to trigger the end of training run Reviewed-by: iklam ! README.md ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp ! src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp ! src/hotspot/cpu/s390/templateInterpreterGenerator_s390.cpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/interp_masm_x86.hpp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_Runtime1.cpp ! src/hotspot/share/cds/cdsConfig.cpp ! src/hotspot/share/cds/cdsConfig.hpp + src/hotspot/share/cds/cdsEndTrainingUpcall.cpp + src/hotspot/share/cds/cdsEndTrainingUpcall.hpp ! src/hotspot/share/cds/cds_globals.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/cds/metaspaceShared.hpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/compiler/methodMatcher.cpp ! src/hotspot/share/compiler/methodMatcher.hpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/interpreter/abstractInterpreter.cpp ! src/hotspot/share/interpreter/abstractInterpreter.hpp ! src/hotspot/share/interpreter/templateInterpreterGenerator.cpp ! src/hotspot/share/interpreter/templateInterpreterGenerator.hpp ! src/hotspot/share/interpreter/zero/zeroInterpreterGenerator.cpp ! src/hotspot/share/interpreter/zero/zeroInterpreterGenerator.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/methodFlags.hpp ! src/hotspot/share/opto/graphKit.hpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/opto/parseHelper.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/runtime.hpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/init.cpp + src/hotspot/share/runtime/methodDetails.cpp + src/hotspot/share/runtime/methodDetails.hpp + src/hotspot/share/runtime/runtimeUpcallNop.cpp + src/hotspot/share/runtime/runtimeUpcallNop.hpp + src/hotspot/share/runtime/runtimeUpcalls.cpp + src/hotspot/share/runtime/runtimeUpcalls.hpp ! src/hotspot/share/services/diagnosticCommand.cpp ! src/hotspot/share/services/diagnosticCommand.hpp ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/native/libjava/System.c

1 0

git: openjdk/leyden: premain-temp-merge-after-jep-483: Fix SCCache crashes
by duke 23 Nov '24

23 Nov '24

Changeset: ff46e8e6 Branch: premain-temp-merge-after-jep-483 Author: Vladimir Ivanov <vladimir.x.ivanov(a)oracle.com> Date: 2024-11-22 16:00:25 +0000 URL: https://git.openjdk.org/leyden/commit/ff46e8e6a4c2a1121a17b42a1e8764e457ae0… Fix SCCache crashes ! src/hotspot/share/code/SCCache.cpp

1 0

Temp branch for merging JEP 483 into leyden/premain
by ioi.lam＠oracle.com 22 Nov '24

22 Nov '24

As mentioned in today's Leyden meeting, I have merged JEP 483 into premain in my local repo. Since there are some new failures, I've put the merged version in a temporary branch: https://github.com/openjdk/leyden/tree/premain-temp-merge-after-jep-483 [1] I have disabled some of the new CDS optimizations. See cdsConfig.cpp // FIXME -- leyden+JEP483 merge { FLAG_SET_ERGO(ArchiveDynamicProxies, false); FLAG_SET_ERGO(ArchiveLoaderLookupCache, false); FLAG_SET_ERGO(ArchivePackages, false); FLAG_SET_ERGO(ArchiveProtectionDomains, false); FLAG_SET_ERGO(ArchiveReflectionData, false); The reason is that JEP 483 is more aggressive in picking classes to be AOT-initialized. For example, with the -XX:+ArchiveProtectionDomains option, after the 483 merge, the jdk.internal.loader.NativeLibraries class is AOT-initialized. As a result, the static field nativeLibraryLockMap is archived, so it remembers all the native libs that were loaded during the assembly phase. When we attempt to load these libs again during production, we get an "is being loaded in another classloader" error. Therefore, we need more refactoring of the core libraries (such as adding runtimeSetup() methods) before some of these optimizations can be enabled again. [2] There's a new failure in the AOT compiler. Could someone familiar with the compiler take a look? # Internal Error (/opt/mach5/mesos/work_dir/slaves/3fe4557b-066a-4392-9b05-ef874140c35c-S62/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/cfba4e4e-51a1-47f1-9d82-c6f09de94dd2/runs/e5810681-4ef9-46d2-9b14-5ef945fda550/workspace/open/src/hotspot/share/code/SCCache.cpp:4205), pid=1235, tid=1253 # fatal error: Address 0x00007fe4817c5d30 for <unknown> is missing in SCA table V [libjvm.so+0x366795] SCAddressTable::id_for_address(unsigned char*, RelocIterator, CodeBuffer*) [clone .part.0]+0x455 (SCCache.cpp:4205) V [libjvm.so+0x36df0a] SCCache::write_relocations(CodeBuffer*, unsigned int&)+0x68a (SCCache.cpp:4147) V [libjvm.so+0x3702d2] SCCache::write_nmethod(methodHandle const&, int, int, CodeOffsets*, int, DebugInformationRecorder*, Dependencies*, CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*, CompLevel, bool, bool, bool, bool, bool, bool)+0xb92 (SCCache.cpp:3335) V [libjvm.so+0x3707b2] SCCache::store_nmethod(methodHandle const&, int, int, CodeOffsets*, int, DebugInformationRecorder*, Dependencies*, CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*, CompLevel, bool, bool, bool, bool, bool, bool)+0x182 (SCCache.cpp:3102) V [libjvm.so+0x96ac99] ciEnv::register_method(ciMethod*, int, CodeOffsets*, int, CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*, bool, bool, bool, bool, bool, bool, int, bool, SCCEntry*)+0xcf9 (ciEnv.cpp:1099) V [libjvm.so+0x161c22e] PhaseOutput::install_code(ciMethod*, int, AbstractCompiler*, bool, bool)+0x15e (output.cpp:3445) V [libjvm.so+0xa9f46b] Compile::Code_Gen()+0x5cb (compile.cpp:3036) V [libjvm.so+0xaa216f] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1c7f (compile.cpp:886) V [libjvm.so+0x8dfde1] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x261 (c2compiler.cpp:172) V [libjvm.so+0xaaff07] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xcb7 (compileBroker.cpp:2626) V [libjvm.so+0xab2448] CompileBroker::compiler_thread_loop()+0x758 (compileBroker.cpp:2272) V [libjvm.so+0xfac4ce] JavaThread::thread_main_inner()+0xee (javaThread.cpp:774) On Linux/x64, this can be reliably reproduced with test/hotspot/jtreg/runtime/cds/appcds/applications/QuarkusGettingStarted.java#leyden On aarch64 (Linux or MacOS), this failure seems to affect many more test cases. Also, instead of <unknown>, we see # Internal Error (SCCache.cpp:4159), pid=87789, tid=28419 # fatal error: Address 0x0000000114d4aa80 for Stub:_large_arrays_hashcode_boolean is missing in SCA table Thanks - Ioi

2 1