June 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

Crash when dumping cds map file
by Ashutosh Mehra 06 Jul '24

06 Jul '24

I encountered a crash when dumping the cds map with 1-step workflow. The crash happens in the forked JVM during the assembly phase of the training run. To recreate the crash, execute the training run with -Xlog:cds+map=trace:file=cds.map:none:filesize=0 option. # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f4e8a209cb6, pid=152509, tid=152510 # # JRE version: OpenJDK Runtime Environment (23.0) (slowdebug build 23-internal-adhoc.asmehra.leyden) # Java VM: OpenJDK 64-Bit Server VM (slowdebug 23-internal-adhoc.asmehra.leyden, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x409cb6] Klass::is_instance_klass() const+0x10 # # Core dump will be written. Default location: /home/asmehra/data/ashu-mehra/leyden/test/hotspot/jtreg/premain/quarkus-getting-started/core.152509 # # An error report file with more information is saved as: # /home/asmehra/data/ashu-mehra/leyden/test/hotspot/jtreg/premain/quarkus-getting-started/hs_err_pid152509.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # [75.250s][error ][cds] Child process finished; status = 134 Backtrace for the crashing thread: #11 0x00007f4e8a209cb6 in Klass::is_instance_klass (this=0x0) at /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/klass.hpp:683 #12 0x00007f4e8afa8894 in Klass::external_name (this=0x0) at /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/klass.cpp:905 #13 0x00007f4e8b126447 in Method::print_external_name (os=0x7f4e89dfd130, klass=0x0, method_name=0x8011e8588, signature=0x8011ab858) at /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/method.cpp:228 #14 0x00007f4e8b1263b6 in Method::external_name (klass=0x0, method_name=0x8011e8588, signature=0x8011ab858) at /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/method.cpp:222 #15 0x00007f4e8b1262e1 in Method::external_name (this=0x800fd1920) at /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/method.cpp:213 #16 0x00007f4e8a492b0d in ArchiveBuilder::CDSMapLogger::log_method (m=0x800fd1920, runtime_dest=0x801039cd8 "", type_name=0x7f4e8b7d40fc "Method", bytes=128, current=0x7f4e8401d900) at /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1194 #17 0x00007f4e8a492d66 in ArchiveBuilder::CDSMapLogger::log_metaspace_objects (region=0x7f4e89dfe740, src_objs=0x7f4e89dfe860) at /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1228 #18 0x00007f4e8a492a2b in ArchiveBuilder::CDSMapLogger::log_metaspace_region (name=0x7f4e8b7d8af0 "rw region", region=0x7f4e89dfe740, src_objs=0x7f4e89dfe860) at /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1182 #19 0x00007f4e8a4940f4 in ArchiveBuilder::CDSMapLogger::log (builder=0x7f4e89dfe630, mapinfo=0x7f4e85017bb0, heap_info=0x7f4e89dfd4f0, bitmap=0x7f4e857bf850 "\t\222\004I\222$\t\210\210\210\001\b\200", bitmap_size_in_bytes=655824) at /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1502 #20 0x00007f4e8a48f2a5 in ArchiveBuilder::write_archive (this=0x7f4e89dfe630, mapinfo=0x7f4e85017bb0, heap_info=0x7f4e89dfd4f0) at /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1560 #21 0x00007f4e8b11d249 in MetaspaceShared::write_static_archive (builder=0x7f4e89dfe630, mapinfo=0x7f4e85017bb0, heap_info=0x7f4e89dfd4f0) at /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/metaspaceShared.cpp:988 #22 0x00007f4e8b11d1ac in MetaspaceShared::preload_and_dump_impl (builder=..., __the_thread__=0x7f4e8401d900) at /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/metaspaceShared.cpp:976 #23 0x00007f4e8b11c5fd in MetaspaceShared::preload_and_dump () at /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/metaspaceShared.cpp:767 #24 0x00007f4e8b53bca2 in Threads::create_vm (args=0x7f4e89dfedd0, canTryAgain=0x7f4e89dfecd3) at /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/runtime/threads.cpp:900 #25 0x00007f4e8ada2821 in JNI_CreateJavaVM_inner (vm=0x7f4e89dfee20, penv=0x7f4e89dfee28, args=0x7f4e89dfedd0) at /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/prims/jni.cpp:3581 #26 0x00007f4e8ada2c81 in JNI_CreateJavaVM (vm=0x7f4e89dfee20, penv=0x7f4e89dfee28, args=0x7f4e89dfedd0) at /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/prims/jni.cpp:3672 #27 0x00007f4e8ce0f84f in InitializeJVM (pvm=0x7f4e89dfee20, penv=0x7f4e89dfee28, ifn=0x7f4e89dfee70) at /home/asmehra/data/ashu-mehra/leyden/src/java.base/share/native/libjli/java.c:1550 Checking up the CDS map generated for the cds preimage shows some methods for which their InstanceKlass is null. This results in the crash seen above when such methods are printed as part of the CDS map file during the assembly phase. These methods are of the form: java.lang.Object java.lang.invoke.LambdaForm$MH/0x800000090.invoke(java.lang.Object, java.lang.Object) Interestingly -Xlog:cds=info shows such classes are skipped when generating the preimage as they are hidden classes: Skipping java/lang/invoke/LambdaForm$MH+0x800000090: Hidden class In the CDS map file for the preimage I also noticed that such methods are only referenced through MethodTrainingData -> _final_profile -> _method. So it looks like although we excluded such classes from the CDS archive, we don't exclude their training data. There is code for cleaning up the training data [0] , but it doesn't remove the training data for classes that have been excluded, unless I misunderstood the code. Not sure if it is intentional or a bug. If we do need to keep the training data for such methods, then we would need to handle the case of null InstanceKlass in the CDSMapLogger to avoid crashing. [0] https://github.com/openjdk/leyden/blob/8716f47ef49c829e2384474577ff468a732b… Thanks, - Ashutosh Mehra

4 6

git: openjdk/leyden: premain-ea: 3 new changesets
by duke 28 Jun '24

28 Jun '24

Changeset: dc69d066 Author: Vladimir Kozlov <kvn(a)openjdk.org> Committer: Vladimir Kozlov <vladimir.kozlov(a)oracle.com> Date: 2024-06-25 16:04:03 +0000 URL: https://git.openjdk.org/leyden/commit/dc69d066e922b7c18d8329ea3dd0c1a16abda… 8334421: assert(!oldbox->is_unbalanced()) failed: this should not be called for unbalanced region Reviewed-by: vlivanov, thartmann ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/locknode.hpp ! src/hotspot/share/opto/macro.cpp + test/hotspot/jtreg/compiler/locks/TestCoarsenedAndNotEscapedLocksElimination.java Changeset: 5b27856a Author: Vladimir Kozlov <kvn(a)openjdk.org> Committer: Vladimir Kozlov <vladimir.kozlov(a)oracle.com> Date: 2024-06-27 16:06:35 +0000 URL: https://git.openjdk.org/leyden/commit/5b27856a66d828105a69e0ca6551698fd1ead… 8335220: C2: Missing check for Opaque4 node in EscapeAnalysis Reviewed-by: chagedorn, cslucas ! src/hotspot/share/opto/escape.cpp Changeset: c27385e3 Author: Vladimir Kozlov <kvn(a)openjdk.org> Committer: Vladimir Kozlov <vladimir.kozlov(a)oracle.com> Date: 2024-06-28 19:36:00 +0000 URL: https://git.openjdk.org/leyden/commit/c27385e3a9a150ec9650282d39275c4b53241… 8335221: Some C2 intrinsics incorrectly assume that type argument is compile-time constant Reviewed-by: roland, chagedorn ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp

1 0

git: openjdk/leyden: created branch premain-ea based on the branch premain containing 0 unique commits
by duke 27 Jun '24

27 Jun '24

The new branch premain-ea is currently identical to the premain branch.

1 0

generate cds file for springboot project,but core dump
by dreamlike_ocean lei 27 Jun '24

27 Jun '24

Leyden-dev team： I am writing to report an issue I encountered while using the new Leyden EA build for various tests. Specifically, when generating CDS (Class Data Sharing) files for a Spring Boot project on Linux x86_64, I encountered a core dump. Here are the details: Project repository: https://github.com/dreamlike-ocean/leydenPlayground (In the project root directory, you will find the corresponding core dump and logs related to this issue.) Reproduction steps: 1,Navigate to the project root directory. 2,Execute the following build command: `mvn clean package -pl leyden-spring && java -XX:CacheDataStore=spring-leyden.cds -jar leyden-spring/target/leyden-spring-0.0.1.jar` I appreciate your assistance in resolving this matter. Please let me know if you need any additional information. use the following build toolchain： Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9) Maven home: /home/dreamlike/.sdkman/candidates/maven/current Java version: 24-leydenpremain, vendor: Oracle Corporation, runtime: /home/dreamlike/jdks/leyden-jdk-24 Default locale: zh_CN, platform encoding: UTF-8 OS name: "linux", version: "6.8.0-31-generic", arch: "amd64", family: "unix" Best regards, dreamlike

4 5

git: openjdk/leyden: premain: 2 new changesets
by duke 27 Jun '24

27 Jun '24

Changeset: ce790adc Author: Calvin Cheung <calvin.cheung(a)oracle.com> Date: 2024-06-27 04:50:28 +0000 URL: https://git.openjdk.org/leyden/commit/ce790adc3c2bf08334acba2b445f0c0ea1b3d… remove leftover commented code during last merge ! src/hotspot/share/runtime/threads.cpp Changeset: 8716f47e Author: Calvin Cheung <calvin.cheung(a)oracle.com> Date: 2024-06-27 04:50:52 +0000 URL: https://git.openjdk.org/leyden/commit/8716f47ef49c829e2384474577ff468a732b9… Merge branch 'premain' of github.com:openjdk/leyden into premain

1 0

G1 GC verification failure in production run
by Ashutosh Mehra 26 Jun '24

26 Jun '24

Sanne (cc-ed here) reported (using internal communication) he was getting random crashes in his setup that utilizes the premain feature when running with G1 gc. I was able to dig further into it and found the difference in heap size in production run compared to the training run can cause g1 gc barriers to not work properly, resulting in dangling references. An easy way to reproduce is to run the quarkus-getting-started [0] app using 1-step workflow and pass -XX:+UseG1GC -Xmx128m -XX:+VerifyBeforeGC option to the production run. It results in gc verification failure: [4.703s][error][gc,verify] ---------- [4.703s][error][gc,verify] Missing rem set entry: [4.703s][error][gc,verify] Field 0x0000000087f47148 of obj 0x0000000087f47120 in region 125:(O)[0x0000000087f00000,0x0000000088000000,0x0000000088000000] [4.703s][error][gc,verify] java.util.concurrent.ConcurrentHashMap [4.703s][error][gc,verify] {0x0000000087f47120} - klass: 'java/util/concurrent/ConcurrentHashMap' [4.703s][error][gc,verify] - ---- fields (total size 8 words): [4.703s][error][gc,verify] - transient 'keySet' 'Ljava/util/Set;' @12 null (0x00000000) [4.703s][error][gc,verify] - transient 'values' 'Ljava/util/Collection;' @16 null (0x00000000) [4.703s][error][gc,verify] - private volatile transient 'sizeCtl' 'I' @20 24 (0x00000018) [4.703s][error][gc,verify] - private volatile transient 'baseCount' 'J' @24 18 (0x0000000000000012) [4.703s][error][gc,verify] - private volatile transient 'transferIndex' 'I' @32 0 (0x00000000) [4.703s][error][gc,verify] - private volatile transient 'cellsBusy' 'I' @36 0 (0x00000000) [4.703s][error][gc,verify] - volatile transient 'table' '[Ljava/util/concurrent/ConcurrentHashMap$Node;' @40 a 'java/util/concurrent/ConcurrentHashMap$Node'[32] {0x0000000087ce4208} (0x00f9c841) [4.703s][error][gc,verify] - private volatile transient 'nextTable' '[Ljava/util/concurrent/ConcurrentHashMap$Node;' @44 null (0x00000000) [4.703s][error][gc,verify] - private volatile transient 'counterCells' '[Ljava/util/concurrent/ConcurrentHashMap$CounterCell;' @48 null (0x00000000) [4.703s][error][gc,verify] - private transient 'keySet' 'Ljava/util/concurrent/ConcurrentHashMap$KeySetView;' @52 null (0x00000000) [4.703s][error][gc,verify] - private transient 'values' 'Ljava/util/concurrent/ConcurrentHashMap$ValuesView;' @56 null (0x00000000) [4.703s][error][gc,verify] - private transient 'entrySet' 'Ljava/util/concurrent/ConcurrentHashMap$EntrySetView;' @60 null (0x00000000) [4.703s][error][gc,verify] points to obj 0x0000000087ce4208 in region 122:(E)[0x0000000087c00000,0x0000000087d00000,0x0000000087d00000] remset Complete [4.703s][error][gc,verify] [Ljava.util.concurrent.ConcurrentHashMap$Node; [4.703s][error][gc,verify] {0x0000000087ce4208} - klass: 'java/util/concurrent/ConcurrentHashMap$Node'[] [4.703s][error][gc,verify] - length: 32 [4.703s][error][gc,verify] - 0 : null [4.703s][error][gc,verify] - 1 : null [4.703s][error][gc,verify] - 2 : null [4.703s][error][gc,verify] - 3 : null [4.703s][error][gc,verify] - 4 : a 'java/util/concurrent/ConcurrentHashMap$Node'{0x0000000087ce3df0} [4.703s][error][gc,verify] - 5 : a 'java/util/concurrent/ConcurrentHashMap$Node'{0x0000000087ce3ec0} [4.703s][error][gc,verify] - 6 : a 'java/util/concurrent/ConcurrentHashMap$Node'{0x0000000087ce44e8} [4.703s][error][gc,verify] - 7 : a 'java/util/concurrent/ConcurrentHashMap$Node'{0x0000000087ce4480} [4.703s][error][gc,verify] - 8 : a 'java/util/concurrent/ConcurrentHashMap$Node'{0x0000000087ce41e8} [4.703s][error][gc,verify] - 9 : null [4.703s][error][gc,verify] - 10 : null [4.703s][error][gc,verify] - 11 : a 'java/util/concurrent/ConcurrentHashMap$Node'{0x0000000087ce43b0} [4.703s][error][gc,verify] - 12 : null [4.703s][error][gc,verify] - 13 : a 'java/util/concurrent/ConcurrentHashMap$Node'{0x0000000087ce3e58} [4.703s][error][gc,verify] - 14 : null [4.703s][error][gc,verify] - 15 : null [4.703s][error][gc,verify] - 16 : a 'java/util/concurrent/ConcurrentHashMap$Node'{0x0000000087ce4418} [4.703s][error][gc,verify] - 17 : a 'java/util/concurrent/ConcurrentHashMap$Node'{0x0000000087ce4138} [4.703s][error][gc,verify] - 18 : null [4.703s][error][gc,verify] - 19 : a 'java/util/concurrent/ConcurrentHashMap$Node'{0x0000000087ce4088} [4.703s][error][gc,verify] - 20 : null [4.703s][error][gc,verify] - 21 : null [4.703s][error][gc,verify] - 22 : null [4.703s][error][gc,verify] - 23 : null [4.703s][error][gc,verify] - 24 : a 'java/util/concurrent/ConcurrentHashMap$Node'{0x0000000087ce42b8} [4.703s][error][gc,verify] - 25 : null [4.703s][error][gc,verify] - 26 : null [4.703s][error][gc,verify] - 27 : a 'java/util/concurrent/ConcurrentHashMap$Node'{0x0000000087ce41a0} [4.703s][error][gc,verify] - 28 : null [4.703s][error][gc,verify] - 29 : null [4.703s][error][gc,verify] - 30 : null [4.703s][error][gc,verify] - 31 : a 'java/util/concurrent/ConcurrentHashMap$Node'{0x0000000087ce3f70} [4.703s][error][gc,verify] Obj head CV = 255, field CV = 255. [4.703s][error][gc,verify] ---------- [4.723s][error][gc,verify] Heap after failed verification (kind 0): [4.723s][error][gc,verify] garbage-first heap total reserved 131072K, committed 131072K, used 24363K [0x0000000080200000, 0x0000000088200000) [4.723s][error][gc,verify] region size 1024K, 21 young (21504K), 0 survivors (0K) [4.723s][error][gc,verify] Metaspace used 3891K, committed 4096K, reserved 1114112K [4.723s][error][gc,verify] class space used 63K, committed 192K, reserved 1048576K It turns out g1 barriers rely on G1HeapRegion::LogOfHRGrainBytes [1] [2] to determine if a reference and the pointee both belong to the same heap region or not. If they are in the same region, then the card for the reference is not marked dirty. The value of G1HeapRegion::LogOfHRGrainBytes is embedded in the compiled code generated by C1 and C2. Interestingly G1HeapRegion::LogOfHRGrainBytes [3] is determined ergonomically based on the heap size. For instance on my system when Xmx is not specified, G1HeapRegion::LogOfHRGrainBytes is 23 (for heap region size of 8M). For Xmx128m, the G1HeapRegion::LogOfHRGrainBytes is 20 (for heap region size of 1M). So if Xmx is not specified in the training run then the AOT code would have embedded 23 as the value for G1HeapRegion::LogOfHRGrainBytes. During production run if Xmx128m is used, then the g1 barrier in the AOT code could incorrectly determine that the reference and the pointee are in the same region when they are not, and would then skip marking the card as dirty, resulting in gc verification failures seen above. As a workaround for now, we can manually specify G1HeapRegionSize to be the same in both training and production run, but ideally we shouldn't need to do that. For a long term solution Andrew Dinn suggested loading the value for G1HeapRegion::LogOfHRGrainBytes from a thread field. This way we can avoid patching the code or the penalty of a runtime call to fetch the value. Any other ideas on how to fix it? [0] https://github.com/openjdk/leyden/tree/premain/test/hotspot/jtreg/premain/q… [1] https://github.com/openjdk/leyden/blob/d415c65b664cf31167bfd843dcf1805530b8… [2] https://github.com/openjdk/leyden/blob/d415c65b664cf31167bfd843dcf1805530b8… [3] https://github.com/openjdk/leyden/blob/d415c65b664cf31167bfd843dcf1805530b8… <https://github.com/openjdk/leyden/blob/d415c65b664cf31167bfd843dcf1805530b8…> Thanks, - Ashutosh Mehra

1 0

git: openjdk/leyden: premain: Instead of using ArchiveInvokeDynamic directly, use CDSConfig::is_dumping_invokedynamic()
by duke 26 Jun '24

26 Jun '24

Changeset: d415c65b Author: iklam <ilam3388(a)gmail.com> Date: 2024-06-25 22:11:29 +0000 URL: https://git.openjdk.org/leyden/commit/d415c65b664cf31167bfd843dcf1805530b89… Instead of using ArchiveInvokeDynamic directly, use CDSConfig::is_dumping_invokedynamic() ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/cdsConfig.cpp ! src/hotspot/share/cds/cdsConfig.hpp ! src/hotspot/share/cds/classListParser.cpp ! src/hotspot/share/cds/classPrelinker.cpp ! src/hotspot/share/cds/finalImageRecipes.cpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/lambdaFormInvokers.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/prims/methodHandles.cpp

1 0

git: openjdk/leyden: premain: Removed incorrect message "Cannot dump shared archive while using shared archive"
by duke 24 Jun '24

24 Jun '24

Changeset: ce3ce7aa Author: iklam <ilam3388(a)gmail.com> Date: 2024-06-24 12:23:47 +0000 URL: https://git.openjdk.org/leyden/commit/ce3ce7aadb4a5e6487541164cbf078ab60c04… Removed incorrect message "Cannot dump shared archive while using shared archive" ! src/hotspot/share/cds/cdsConfig.cpp

1 0

Leyden EA Build is available
by ioi.lam＠oracle.com 21 Jun '24

21 Jun '24

We are happy to announce the availability of the Leyden EA Build: https://jdk.java.net/leyden/ This is the culmination of more than a year of work in the Leyden Project. The goal of this first release is to show the results of our work and get feedback on it. So far we have focused on improving start-up time, but we plan to explore other Leyden optimizations in future releases. We are seeing 2~3x start-up improvements with preliminary testing of popular application frameworks. This work would not have been possible without the participation of the Java community. We would like to thank everyone who has contributed to the Leyden project, especially our partners at Red Hat and Spring for their ideas, time and energy to make this project a success. Details of the Leyden EA Build, as well as HOWTO instructions can be found at the release notes: https://github.com/openjdk/leyden/blob/leyden-ea1-release-notes/README.md Highlights: - A unified Cache Data Store (CDS) archive that supports multiple types of optimization artifacts - Loaded Classes in the CDS archive - Class loader lookup cache - Archived Method Profiles - Ahead-of-time compilation of Java methods - Ahead-of-time resolution of constant pool entries - Ahead-of-time generation of Dynamic Proxies and reflection data Please give it a try. We would love to hear your experiences, positive or negative, so that we know how to improve the implementation with the hope of eventual integration into future Java releases. Please send your feedback via e-mail to leyden-dev(a)openjdk.org. Leyden Project Team @ Oracle

1 0