January 2024 - leyden-dev

Statistics about CDS effectiveness
by Stephane Nicoll 11 Jun '24

11 Jun '24

Hey, I hope this mailing list is the right place for this. I am working with Sébastien Deleuze on the Spring team and we've been focusing quite a bit on CDS lately and how it can be easily leveraged by our user base. One thing we quickly found out was that the cache can be more or less effective depending on the way you start the app (classloaders, non deterministic list of jar files, etc). Initially, we were testing the startup time and comparing when CDS wasn't enabled. I think there must be a better way and, for the lack of finding one, I've developed a (very) pragmatic approach of parsing the JVM logs and producing a report[1]. The tool has improved a bit for our own use case, creating the cache and providing a report of the warnings that were issued (to spot packages that couldn't be managed and why). Parsing the logs is good enough for our little testing there but we were wondering if there was an appetite (or need) to productize this. We were thinking that JFR events could be an option. Thanks, S. [1] https://github.com/snicoll/cds-log-parser -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

2 2

The 'modules' image (jimage) packaged JDK resources
by Jiangli Zhou 13 Feb '24

13 Feb '24

As part of the discussions of bringing https://github.com/openjdk/leyden/tree/hermetic-java-runtime related work into OpenJDK mainline under the leyden project, some of us (cc'ed on the email) have started brainstorming (in several zoom meetings) the idea of placing JDK resources in the modules image (jimage). The resources would include conf/*, lib/<resources>, etc in a regular JDK binary. In the hermetic-java-runtime prototype, the JDK resources are packaged into an executable JAR image as normal JAR entries. At runtime, accessing these resources goes through a JavaHome <https://github.com/openjdk/leyden/blob/hermetic-java-runtime/src/java.base/…> class using a ZipFileSystem. If JDK resources are part of the modules, the static/hermetic image packaging and runtime accessing becomes further cleaner. I recently prototyped that idea with a jlink plugin and some quick runtime changes to access using Module.getResourceAsStream <https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Modu…> (not in the hermetic-java-runtime branch yet). The quick prototype indicates it is feasible from an implementation point of view. Following are a few points that have been discussed among us for more broad discussions: - This probably will involve specification changes in order to place the JDK resources into the modules image. Particularly, the conf/* resource files were intended to be user configurable (pointed out by Alan). Alan has been looking into those parts. - Where should the resources be placed within the modules image? For example, if conf/security/java.security is written (using the new jlink plugin) into the image as /java.base/java.security, runtime can just access "java.security" resource using the "java.base" module (via getResourceAsStream()). Alternatively, if the file is written as /java.base/conf/security/java.security, the conf/security package needs to be added for the java.base module. Thoughts and input? Thanks! Jiangli

2 4

git: openjdk/leyden: hermetic-java-runtime: Support accessing hermetic `modules` image (in host JDK only, currently) from jrtfs.
by duke 23 Jan '24

23 Jan '24

Changeset: e1f35d09 Author: Jiangli Zhou <jianglizhou(a)google.com> Date: 2024-01-23 14:38:50 +0000 URL: https://git.openjdk.org/leyden/commit/e1f35d09ace675d8ff5093885313b5067a326… Support accessing hermetic `modules` image (in host JDK only, currently) from jrtfs. - Add jdk.internal.jimage.HermeticImageHelper. This class is packaged together with the jrtfs implementation classes. This solution is suggested by Liam Miller-Cushon, to allow properly supporting different cases described below. HermeticImageHelper's hermetic states are initialized during jdk.internal.misc.JavaHome <clinit> if executed in hermetic Java mode. HermeticImageHelper is used by jdk.internal.jrtfs.SystemImage if its CodeSource is null (target JDK == current JDK). - Explicitly initialize jdk.internal.misc.JavaHome during VM initialization. This provides better control of initialization order related to JavaHome. Discussed the approach (on the high-level) and different use cases with Alan Bateman, Liam Miller-Cushon, Ron Pressler and Severin Gehwolf. Following are the different cases: Case 1 (new case): supported by this PR - Host JDK = Target JDK - Tool (host JDK) executes in hermetic mode Case 2 (existing) - Host JDK = Target JDK - Tool (host JDK) executes non-hermetic Case 3 (new case): not yet supported - Host JDK != Target JDK - Tool (host JDK) executes in hermetic mode - Target JDK hermetic packaged Case 4 (new case): works with existing OpenJDK jrtfs implementation - Host JDK != Target JDK - Tool (host JDK) executes in hermetic mode - Target JDK not hermetic packaged Case 5 (new case): not yet supported - Host JDK != Target JDK - Tool (host JDK) executes non-hermetic - Tool (host JDK) executes in hermetic mode Case 6 (existing) - Host JDK != Target JDK - Tool (host JDK) executes non-hermetic - Target JDK not hermetic packaged Case 7 (existing) - Host JDK != Target JDK - Tool runs on an older JDK version without hermetic support ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/runtime/threads.cpp ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java + src/java.base/share/classes/jdk/internal/jimage/HermeticImageHelper.java ! src/java.base/share/classes/jdk/internal/jrtfs/SystemImage.java ! src/java.base/share/classes/jdk/internal/misc/JavaHome.java

1 0

premain: performance sniff tests
by Ashutosh Mehra 23 Jan '24

23 Jan '24

Hi, We have been interested in persisting the profiling data in the CDS archive with the intention of improving the application's warmup time. And now that the premain branch is here that does save profile data along with AOT, we started playing with the premain branch to understand its impact on the performance. Our setup uses Springboot Petclinic [0] application and the CDS and shared code archives are generated in a manner similar to this script [1]. Our training run only covers the application startup phase. That means at each step we start the application and shut it down without putting any load on it. Using the archives thus generated I have done few experiments on my local system. In these experiments the application is bound to two cpus. The baseline for comparing the results is the case where the CDS archive does not have any profiling data and there is no shared code archive. The "premain" configuration refers to using a shared code archive and a CDS archive with training data. Here are some initial results: 1. Startup: It is heartening to see start-up time improve by almost 11%. baseline 10.2s premain 9.1s 2. Warmup: This test measures the warmup time by applying load using 1 jmeter thread to get an idea of the ramp-up time to reach the peak throughput. The load is applied for the duration of 300 seconds. The graph [2] for aot+profiling configuration shows interesting behavior. In the initial period premain is ramping up faster than the baseline. Then the slope of the curve for premain reduces significantly and a couple of dips are also seen. Finally the throughput stabilizes. It shows a drastic difference in the warmup time of the application when running with the "premain" config. 3. Peak throughput: Last experiment is to measure peak throughput. It starts with a warm-up phase of 180 seconds using 1 jmeter thread. After the warmup phase the load is applied with 10 jmeter threads for a duration of 5 mins. Last two minutes of throughput is considered for measurement. The graph [3] for this test shows almost a 10% drop in the throughput compared to the baseline. I am sure others would have done similar testing. My questions are: 1. Are these results on the expected lines? 2. Are these tests using the CDS and the shared code (or cached code) archives in the expected manner. 3. Warmup time with the premain branch looks pretty bad which is surprising. Is there any trick I missed in my tests? Is there anything else that needs to be done to get better warmup time? 4. What is the point of creating a new static archive? Shouldn't the applications just create the dynamic archive? 5. I am also wondering if there is any design doc that can be shared that explains the AOT compilation strategy adopted in the premain branch? I have placed my scripts here [4] in case anyone wants to use them to run these tests (you need to build the Petclinic app before using these scripts). Please feel free to share your thoughts. [0] https://github.com/spring-projects/spring-petclinic [1] https://github.com/openjdk/leyden/blob/d960fb15258cc99a1bf7f0b1e94bd8be0660… [2] https://github.com/ashu-mehra/leyden-perf/blob/main/spring/fd82682/tput-t1.… [3] https://github.com/ashu-mehra/leyden-perf/blob/main/spring/fd82682/tput-t10… [4] https://github.com/ashu-mehra/leyden-perf Thanks, - Ashutosh Mehra

7 15

git: openjdk/leyden: hermetic-java-runtime: Load ZipFileSystemProvider using a ServiceLoader directly and create the 'jarFileSystem' using the ZipFileSystemProvider. This is to avoid a circular loading problem during early system initialization when accessing JAR packaged JDK resources (specifically java.security), with user provided FileSystem provider involved.
by duke 23 Jan '24

23 Jan '24

Changeset: 23b228ea Author: Jiangli Zhou <jianglizhou(a)google.com> Date: 2024-01-23 14:16:23 +0000 URL: https://git.openjdk.org/leyden/commit/23b228ea6b67b98e1fb96198b1536a51763ad… Load ZipFileSystemProvider using a ServiceLoader directly and create the 'jarFileSystem' using the ZipFileSystemProvider. This is to avoid a circular loading problem during early system initialization when accessing JAR packaged JDK resources (specifically java.security), with user provided FileSystem provider involved. We discussed with Alan Bateman, Ron Pressler about building the JDK resources into `modules` file. When that's done, accessing hermetic packaged JDK resources would no longer use the ZipFileSystem. ! src/java.base/share/classes/jdk/internal/misc/JavaHome.java

1 0

git: openjdk/leyden: hermetic-java-runtime: Define DEF_STATIC_JNI_OnLoad in libsaproc and statically link it into bin/javastatic.
by duke 23 Jan '24

23 Jan '24

Changeset: 99317d1d Author: Jiangli Zhou <jianglizhou(a)google.com> Date: 2024-01-23 13:16:44 +0000 URL: https://git.openjdk.org/leyden/commit/99317d1d84b980807075fc6b74d7f53447108… Define DEF_STATIC_JNI_OnLoad in libsaproc and statically link it into bin/javastatic. ! make/StaticLink.gmk ! src/jdk.hotspot.agent/share/native/libsaproc/sadis.c

1 0

git: openjdk/leyden: premain: Factor in should_delay()
by duke 22 Jan '24

22 Jan '24

Changeset: e73de845 Author: Igor Veresov <igor.veresov(a)oracle.com> Date: 2024-01-22 13:08:48 +0000 URL: https://git.openjdk.org/leyden/commit/e73de8454e5763ee2ebb451521255ed2774ea… Factor in should_delay() ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/compiler/compilationPolicy.hpp

1 0

Spring team feedback on Leyden-premain optimizations
by Sebastien Deleuze 19 Jan '24

19 Jan '24

Hi, I would like to share the Spring team feedback on Leyden-premain optimizations. I have updated my spring-boot-leyden-demo repository [1] to leverage the new Leyden 1 step workflow [2] that is much simpler to use than the previous 5 steps workflow. It is great to see that we can reuse the same `-Dspring.context.exit=onRefresh` property introduced by Spring Framework 6.1 for Class Data Sharing [3] with this new Class Data Store arrangement. I am not sure if all optimizations are enabled yet, but the data points on my MacBook with Spring Petclinic are already promising, and pretty close to what we observed with the 5 steps workflow: - Executable JAR: 1.55s - Unpacked: 1.26s - Unpacked + Premain: 0.80s - Unpacked + Premain + Spring AOT: 0.56s A few remarks: - We currently observe various warnings [4] - We have to use `-XX:CachedCodeMaxSize` in order to have cached code generation with the "Unpacked + Premain" variant since its generates a cached code of 12M (more than current 10M default limit) - We plan to do more benchmarks on cheap production servers (1 CPU 2G RAM and 2 CPU 4G RAM) I have for now only measured the startup time improvements, not yet the warm up time improvements. I would be interested to know if the Leyden premain branch already provides warm up improvements worth benchmarking with Spring applications. Best regards, Sébastien Deleuze [1] https://github.com/sdeleuze/spring-boot-leyden-demo [2] https://github.com/openjdk/leyden/tree/premain/test/hotspot/jtreg/premain/j… [3] https://spring.io/blog/2023/12/04/cds-with-spring-framework-6-1/#initial-cd… [4] https://gist.github.com/sdeleuze/8d442f9e85b069be0a5b24f3454d39a8 -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

1 0

git: openjdk/leyden: premain: Refactored Leyden test supporting code to jdk.test.lib.cds.CDSAppTester
by duke 18 Jan '24

18 Jan '24

Changeset: 59f97f7a Author: iklam <ilam3388(a)gmail.com> Date: 2024-01-17 21:51:08 +0000 URL: https://git.openjdk.org/leyden/commit/59f97f7a79e4c8dcf0e557ac97a35687c5893… Refactored Leyden test supporting code to jdk.test.lib.cds.CDSAppTester + test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBench.java ! test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBenchDynamic.java + test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBenchLeyden.java + test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBenchLeydenOldWF.java ! test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBenchStatic.java - test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBenchTestBase.java = test/hotspot/jtreg/runtime/cds/appcds/applications/spring-petclinic/SpringPetClinic.java + test/hotspot/jtreg/runtime/cds/appcds/applications/spring-petclinic/SpringPetClinicDynamic.java + test/hotspot/jtreg/runtime/cds/appcds/applications/spring-petclinic/SpringPetClinicLeyden.java + test/hotspot/jtreg/runtime/cds/appcds/applications/spring-petclinic/SpringPetClinicLeydenOldWF.java + test/hotspot/jtreg/runtime/cds/appcds/applications/spring-petclinic/SpringPetClinicStatic.java ! test/hotspot/jtreg/runtime/cds/appcds/leyden/DynamicProxyTest.java ! test/hotspot/jtreg/runtime/cds/appcds/leyden/DynamicProxyTestOldWF.java ! test/hotspot/jtreg/runtime/cds/appcds/leyden/ExcludedClasses.java ! test/hotspot/jtreg/runtime/cds/appcds/leyden/ExcludedClassesOldWF.java ! test/hotspot/jtreg/runtime/cds/appcds/leyden/LeydenHello.java ! test/hotspot/jtreg/runtime/cds/appcds/leyden/LeydenHelloOldWF.java ! test/hotspot/jtreg/runtime/cds/appcds/leyden/LeydenReflection.java ! test/hotspot/jtreg/runtime/cds/appcds/leyden/LeydenReflectionOldWF.java - test/hotspot/jtreg/runtime/cds/appcds/leyden/SpringPetClinicOldWF.java - test/lib/jdk/test/lib/LeydenTester.java + test/lib/jdk/test/lib/cds/CDSAppTester.java

1 0

git: openjdk/leyden: premain: 2 new changesets
by duke 17 Jan '24

17 Jan '24

Changeset: 96997843 Author: iklam <ilam3388(a)gmail.com> Date: 2024-01-16 20:10:30 +0000 URL: https://git.openjdk.org/leyden/commit/969978431e1cf772f5fc83d6b7808620fb804… updated test/hotspot/jtreg/runtime/cds/appcds/leyden/SpringPetClinic.java to use version 3.2.0 ! test/hotspot/jtreg/runtime/cds/appcds/leyden/SpringPetClinic.java Changeset: 02bc149e Author: iklam <ilam3388(a)gmail.com> Date: 2024-01-16 20:13:24 +0000 URL: https://git.openjdk.org/leyden/commit/02bc149e2e4f81cf8daf35bc9838fbaf6f213… updated SpringPetClinic.java jtreg test to add -Dspring.aot.enabled=true ! test/hotspot/jtreg/runtime/cds/appcds/leyden/SpringPetClinic.java

1 0