From duke at openjdk.org Mon Apr 1 05:21:53 2024 From: duke at openjdk.org (duke) Date: Mon, 1 Apr 2024 05:21:53 GMT Subject: git: openjdk/leyden: premain: 2 new changesets Message-ID: Changeset: e2902a0e Author: iklam Date: 2024-03-27 11:39:38 +0000 URL: https://git.openjdk.org/leyden/commit/e2902a0ed7ba1517e57c050f1040e508f5c08128 Quick preloading of classes for the boot loader without calling SystemDictionary::load_instance_class() ! src/hotspot/share/cds/classPreloader.cpp ! src/hotspot/share/cds/classPreloader.hpp Changeset: 6c0c6ff3 Author: iklam Date: 2024-03-31 22:05:51 +0000 URL: https://git.openjdk.org/leyden/commit/6c0c6ff365c18b6a94fc30dfdc5032ae8c4be5a5 Cleaned up ClassLinker APIs for pre-resolution of ConstantPool entries ! src/hotspot/share/cds/classPrelinker.cpp ! src/hotspot/share/cds/classPrelinker.hpp ! src/hotspot/share/cds/dumpAllocStats.hpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/constantPool.hpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/cpCache.hpp ! test/hotspot/jtreg/runtime/cds/appcds/applications/spring-petclinic/SpringPetClinic.java From jianglizhou at google.com Tue Apr 2 19:16:40 2024 From: jianglizhou at google.com (Jiangli Zhou) Date: Tue, 2 Apr 2024 12:16:40 -0700 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> Message-ID: Hi Magnus, In today's zoom meeting with Alan, Ron, Liam and Chuck, we (briefly) discussed how to move forward contributing the static Java related changes (additional runtime fixes/enhancements on top of the existing static support in JDK) from https://github.com/openjdk/leyden/tree/hermetic-java-runtime to JDK mainline. Just a bit more details/context below, which may be useful for others reading this thread. The https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch currently contains following for supporting hermetic Java (without the launcher work for runtime support): 1. Build change for linking the Java launcher (as bin/javastatic) with JDK/hotspot static libraries (.a), mainly in https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk. The part for creating the complete sets of static libraries (including libjvm.a) has already been included in the mainline since last year. https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk is in a very raw state and is intended to demonstrate the capability of building a static Java launcher. 2. Additional runtime fixes/enhancements on top of the existing static support in JDK, e.g. support further lookup dynamic native library if the built-in native library cannot be found. 3. Some initial (prototype) work on supporting hermetic JDK resource files in the jimage (JDK modules image). To move forward, one of the earliest items needed is to add the capability of building the fully statically linked Java launcher in JDK mainline. The other static Java runtime changes can be followed up after the launcher linking part, so they can be built and tested as individual PRs created for the JDK mainline. Magnus, you have expressed interest in helping get the launcher linking part (refactor from https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk) into JDK mainline. What's your thought on prioritizing the launcher static linking part before other makefile clean ups for static libraries? Thanks! Jiangli On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: > On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou > wrote: > > > > Hi Magnus, > > > > Thanks for looking into this from the build perspective. > > > > On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie > > wrote: > > > > > > 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. > > > > Some additional hermetic Java related references that are also useful: > > > > - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that > > links to the issues for resolving static linking issues so far > > - https://github.com/openjdk/jdk21/pull/26 is the enhancement for > > building the complete set of static libraries in JDK/VM, particularly > > including libjvm.a > > > > > > > > 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? > > > > I have a similar view as Alan responded in your other email thread. > > Things are still in the early stage for the general solution. > > > > In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime > > branch, when configuring JDK with --with-static-java=yes, the JDK > > binary contains the following extra artifacts: > > > > - static-libs/*.a: The complete set of JDK/VM static libraries > > - jdk/bin/javastatic: A demo Java launcher fully statically linked > > with the selected JDK .a libraries (e.g. it currently statically link > > with the headless) and libjvm.a. It's the standard Java launcher > > without additional work for hermetic Java. > > > > In our prototype for hermetic Java, we build the hermetic executable > > image (a single image) from the following input (see description on > > singlejar packaging tool in > > https://cr.openjdk.org/~jiangli/hermetic_java.pdf): > > > > - A customized launcher (with additional work for hermetic) executable > > fully statically linked with JDK/VM static libraries (.a files), > > application natives and dependencies (e.g. in .a static libraries) > > - JDK lib/modules, JDK resource files > > - Application classes and resource files > > > > Including a JDK library .a into the corresponding .jmod would require > > extracting the .a for linking with the executable. In some systems > > that may cause memory overhead due to the extracted copy of the .a > > files. I think we should consider the memory overhead issue. > > > > One possibility (as Alan described in his response) is for jlink to > > invoke the ld on the build system. jlink could pass the needed JDK > > static libraries and libjvm.a (provided as part of the JDK binary) to > > ld based on the modules required for the application. > > > > I gave a bit more thoughts on this one. For jlink to trigger ld, it > would need to know the complete linker options and inputs. Those > include options and inputs related to the application part as well. In > some usages, it might be easier to handle native linking separately > and pass the linker output, the executable to jlink directly. Maybe we > could consider supporting different modes for various usages > requirements, from static libraries and native linking point of view: > > Mode #1 > Support .jmod packaged natives static libraries, for both JDK/VM .a > and application natives and dependencies. If the inputs to jlink > include .jmods, jlink can extract the .a libraries and pass the > information to ld to link the executable. > > Mode #2 > Support separate .a as jlink input. Jlink could pass the path > information to the .a libraries and other linker options to ld to > create the executable. > > For both mode #1 and #2, jlink would then use the linker output > executable to create the final hermetic image. > > Mode #3 > Support a fully linked executable as a jlink input. When a linked > executable is given to jlink, it can process it directly with other > JDK data/files to create the final image, without native linking step. > > Any other thoughts and considerations? > > Best, > Jiangli > > > > > > > 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. > > > > An alternative with less memory overhead could be using application > > modular JAR and separate .a as the input for jlink. > > > > > 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. > > > > Part of the current effort includes resolving the discovered symbol > > collision issues with static linking. Will respond to your other email > > on the symbol issue separately later. > > > > > > > > 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. > > > > I think we would need both configure flag and special target for the > > static builds. > > > > > 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. > > > > For the potential objcopy work to resolve symbol issues, we can add > > that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We > > have an internal prototype (not included in > > https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done > > by one of colleagues for localizing symbols in libfreetype using > > objcopy. > > > > > > > > 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". > > > > If we want to also build a fully statically linked launcher, maybe > > --with-static-java? Being able to configure either dynamic, static or > > both as you suggested also seems to be a good idea. > > > > > 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. > > > > Completely agree. It would be good to avoid recompiling the .o file > > for static and dynamic builds. As proposed in > > https://bugs.openjdk.org/browse/JDK-8303796: > > > > It's beneficial to be able to build both .so and .a from the same set > > of .o files. That would involve some changes to handle the dynamic JDK > > and static JDK difference at runtime, instead of relying on the > > STATIC_BUILD macro. > > > > > > > > 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. > > > > Renaming or redefining the symbol at build time could cause confusions > > with debugging. That's a concern raised in > > https://github.com/openjdk/jdk/pull/17456 discussions. > > > > Additionally, redefining symbols using tools like objcopy may not > > handle member names referenced in string literals. For example, in > > https://github.com/openjdk/jdk/pull/17456 additional changes are > > needed in assembling and SA to reflect the symbol change. > > > > > > > > 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? > > > > We have done some testing with jtreg SA related tests for the fully > > statically linked `javastatic`. > > > > If we use objcopy to localize symbols in hotspot, it's not yet clear > > what's the impact on SA. We could do some tests. The other question > > that I raised is the supported gcc versions (for partial linking) > > related to the solution. > > > > Best, > > Jiangli > > > > > > > > /Magnus > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Apr 3 01:31:28 2024 From: duke at openjdk.org (duke) Date: Wed, 3 Apr 2024 01:31:28 GMT Subject: git: openjdk/leyden: premain: 166 new changesets Message-ID: <25f11776-3e6c-4938-b1f2-dfe5d56d1e0d@openjdk.org> Changeset: 481473ef Author: Tejesh R Date: 2024-03-21 05:27:10 +0000 URL: https://git.openjdk.org/leyden/commit/481473efce9f51a497e26002c6da52b0ddc9ea8f 8328035: Convert javax/swing/text/html/TableView/7030332/bug7030332.java applet test to main Reviewed-by: abhiscxk, prr - test/jdk/javax/swing/text/html/TableView/7030332/bug7030332.html ! test/jdk/javax/swing/text/html/TableView/7030332/bug7030332.java Changeset: 65d9f119 Author: Abhishek Kumar Date: 2024-03-21 07:30:48 +0000 URL: https://git.openjdk.org/leyden/commit/65d9f119c401c26c9a6436f5c9a513f91bb8c753 8328328: Convert javax/swing/JTabbedPane/4666224/bug4666224.java applet test to main Reviewed-by: honkar, tr ! test/jdk/ProblemList.txt - test/jdk/javax/swing/JTabbedPane/4666224/bug4666224.html - test/jdk/javax/swing/JTabbedPane/4666224/bug4666224.java + test/jdk/javax/swing/JTabbedPane/bug4666224.java Changeset: a5a2eca1 Author: Aggelos Biboudis Date: 2024-03-21 08:02:54 +0000 URL: https://git.openjdk.org/leyden/commit/a5a2eca155bf5d9a1f01d0f3f21bd19dd0a7bd4d 8327683: Crash with primitive type pattern and generic expression in instanceof Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! test/langtools/tools/javac/patterns/PrimitiveInstanceOfPatternOpWithRecordPatterns.java + test/langtools/tools/javac/patterns/PrimitiveInstanceOfPatternOpWithTopLevelPatterns.java ! test/langtools/tools/javac/patterns/PrimitiveInstanceOfTypeComparisonOp.java Changeset: 93d1700f Author: Matthias Baesken Date: 2024-03-21 08:16:50 +0000 URL: https://git.openjdk.org/leyden/commit/93d1700f23d42cb35b6028c5d7d029c035711acf 8328589: unify os::breakpoint among posix platforms Reviewed-by: lucy, asteiner, dholmes ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/posix/os_posix.cpp Changeset: 684678f9 Author: Sidraya Jayagond Committer: Amit Kumar Date: 2024-03-21 08:51:10 +0000 URL: https://git.openjdk.org/leyden/commit/684678f9e83ed0a76541a31356894d170fd421db 8328633: s390x: Improve vectorization of Match.sqrt() on floats Reviewed-by: amitkumar, mdoerr ! src/hotspot/cpu/s390/s390.ad Changeset: 9f5ad433 Author: Renjith Kannath Pariyangad Committer: Tejesh R Date: 2024-03-21 10:29:19 +0000 URL: https://git.openjdk.org/leyden/commit/9f5ad43358a4e209b4cd1c91bcc86b997f371548 8320675: PrinterJob/SecurityDialogTest.java hangs Co-authored-by: Alexey Ivanov Reviewed-by: aivanov, tr ! test/jdk/java/awt/print/PrinterJob/SecurityDialogTest.java Changeset: 68170ae2 Author: Prasanta Sadhukhan Date: 2024-03-21 11:25:27 +0000 URL: https://git.openjdk.org/leyden/commit/68170ae22233462e8925c75c4737be7f0ba9353d 8328238: Convert few closed manual applet tests to main Reviewed-by: tr, aivanov, prr + test/jdk/javax/swing/JFrame/bug4419914.java + test/jdk/javax/swing/text/PaintTest.java + test/jdk/javax/swing/text/bug4148489.java + test/jdk/javax/swing/text/html/StyleSheet/bug4803145.java Changeset: 70067901 Author: Magnus Ihse Bursie Date: 2024-03-21 11:33:36 +0000 URL: https://git.openjdk.org/leyden/commit/700679011e5e9191f5170209454d35cc82953362 8328628: JDK-8328157 incorrectly sets -MT on all compilers in jdk.jpackage Reviewed-by: erikj, jwaters ! make/modules/jdk.jpackage/Lib.gmk Changeset: c434b79c Author: Thomas Stuefe Date: 2024-03-21 12:13:10 +0000 URL: https://git.openjdk.org/leyden/commit/c434b79cff33e08e4518e92ddddae996dffefe29 8327169: serviceability/dcmd/vm/SystemMapTest.java and SystemDumpMapTest.java may fail after JDK-8326586 Reviewed-by: jsjolen, mbaesken ! src/hotspot/share/nmt/memMapPrinter.cpp Changeset: ac2f8e5a Author: Jorn Vernee Date: 2024-03-21 12:34:38 +0000 URL: https://git.openjdk.org/leyden/commit/ac2f8e5af8c88cd13038b113f82bb7c17a38aa40 8327994: Update code gen in CallGeneratorHelper Reviewed-by: mcimadamore ! test/jdk/java/foreign/CallGeneratorHelper.java ! test/jdk/java/foreign/libTestDowncallStack.c ! test/jdk/java/foreign/libTestUpcall.c ! test/jdk/java/foreign/libTestUpcallStack.c ! test/jdk/java/foreign/libVarArgs.c ! test/jdk/java/foreign/shared.h Changeset: bb3e84bd Author: Aleksey Shipilev Date: 2024-03-21 12:36:14 +0000 URL: https://git.openjdk.org/leyden/commit/bb3e84bd1fd8217fcb319de8a0716e44359e3423 8328592: hprof tests fail with -XX:-CompactStrings Reviewed-by: phh, lmesnik, amenkov ! test/lib/jdk/test/lib/hprof/model/JavaObject.java ! test/lib/jdk/test/lib/hprof/model/JavaValueArray.java Changeset: 700d2b91 Author: Alexander Zvegintsev Date: 2024-03-21 13:06:16 +0000 URL: https://git.openjdk.org/leyden/commit/700d2b91defd421a2818f53830c24f70d11ba4f6 8328401: Convert java/awt/Frame/InitialMaximizedTest/InitialMaximizedTest.html applet test to automated Reviewed-by: abhiscxk, prr - test/jdk/java/awt/Frame/InitialMaximizedTest/InitialMaximizedTest.html ! test/jdk/java/awt/Frame/InitialMaximizedTest/InitialMaximizedTest.java Changeset: 43080173 Author: Alexander Zvegintsev Date: 2024-03-21 13:19:22 +0000 URL: https://git.openjdk.org/leyden/commit/43080173e88c8f53cd54c9096c79f3144007fd97 8328631: Convert java/awt/InputMethods/InputMethodsTest/InputMethodsTest.java applet test to manual Reviewed-by: prr - test/jdk/java/awt/InputMethods/InputMethodsTest/InputMethodsTest.html ! test/jdk/java/awt/InputMethods/InputMethodsTest/InputMethodsTest.java Changeset: e41bc42d Author: Richard Reingruber Date: 2024-03-21 14:09:42 +0000 URL: https://git.openjdk.org/leyden/commit/e41bc42deb22615c9b93ee639d04e9ed2bd57f64 8327990: [macosx-aarch64] Various tests fail with -XX:+AssertWXAtThreadSync Reviewed-by: dholmes, stuefe, mdoerr, tholenstein, aph ! src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp ! src/hotspot/share/jfr/jni/jfrJniMethod.cpp ! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp ! src/hotspot/share/jfr/recorder/storage/jfrStorage.cpp ! src/hotspot/share/jfr/support/jfrIntrinsics.cpp ! src/hotspot/share/jfr/writers/jfrJavaEventWriter.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/jvmtiExtensions.cpp Changeset: 725d87bb Author: Prasanta Sadhukhan Date: 2024-03-21 14:46:20 +0000 URL: https://git.openjdk.org/leyden/commit/725d87bbc2abae2ca856d91668f0a494f93fca1c 8328570: Convert closed JViewport manual applet tests to main Reviewed-by: abhiscxk, kizune + test/jdk/javax/swing/JViewport/bug4137282.java + test/jdk/javax/swing/JViewport/bug4217252.java + test/jdk/javax/swing/JViewport/bug4237176.java + test/jdk/javax/swing/JViewport/bug4243479.java + test/jdk/javax/swing/JViewport/bug4750421.java Changeset: 75195aab Author: Harshitha Onkar Date: 2024-03-21 15:30:22 +0000 URL: https://git.openjdk.org/leyden/commit/75195aab497a2d23548128e03f6887283dcaa7e1 8328299: Convert DnDFileGroupDescriptor.html applet test to main Reviewed-by: psadhukhan, tr ! test/jdk/ProblemList.txt - test/jdk/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.html ! test/jdk/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.java Changeset: 581b1e29 Author: Alexander Zvegintsev Date: 2024-03-21 15:31:42 +0000 URL: https://git.openjdk.org/leyden/commit/581b1e29aebd425bade14d2ee46704a16187df5b 8328402: Implement pausing functionality for the PassFailJFrame Reviewed-by: aivanov, prr ! test/jdk/java/awt/regtesthelpers/PassFailJFrame.java Changeset: 16ed1913 Author: Albert Mingkun Yang Date: 2024-03-21 15:47:55 +0000 URL: https://git.openjdk.org/leyden/commit/16ed191329b517766313761c8f3450b4a8285658 8328101: Parallel: Obsolete ParallelOldDeadWoodLimiterMean and ParallelOldDeadWoodLimiterStdDev Reviewed-by: tschatzl, iwalulya, sjohanss ! src/hotspot/share/gc/parallel/parallelArguments.cpp ! src/hotspot/share/gc/parallel/parallel_globals.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.inline.hpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/runtime/arguments.cpp Changeset: 1496b5de Author: Alexey Ivanov Date: 2024-03-21 16:02:17 +0000 URL: https://git.openjdk.org/leyden/commit/1496b5de9004c6a9e43ead5f6e9e88362028a7cc 8327924: Simplify TrayIconScalingTest.java Reviewed-by: honkar, prr ! test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java Changeset: e66788c1 Author: Alexey Ivanov Date: 2024-03-21 16:03:30 +0000 URL: https://git.openjdk.org/leyden/commit/e66788c16563d343f6cccd2807a251ccc6f9b64a 8325179: Race in BasicDirectoryModel.validateFileCache 8238169: BasicDirectoryModel getDirectories and DoChangeContents.run can deadlock Reviewed-by: prr, tr, aturbanov, serb ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java Changeset: ef2bd572 Author: Damon Nguyen Date: 2024-03-21 16:12:47 +0000 URL: https://git.openjdk.org/leyden/commit/ef2bd5721316f208a458fecfffa02ec2c0ea7fe0 8328558: Convert javax/swing/JCheckBox/8032667/bug8032667.java applet test to main Reviewed-by: abhiscxk, psadhukhan, aivanov - test/jdk/javax/swing/JCheckBox/8032667/bug8032667.html - test/jdk/javax/swing/JCheckBox/8032667/bug8032667.java - test/jdk/javax/swing/JCheckBox/8032667/bug8032667_image_diff.java + test/jdk/javax/swing/JCheckBox/bug8032667.java Changeset: cc5cda55 Author: Damon Nguyen Date: 2024-03-21 16:33:39 +0000 URL: https://git.openjdk.org/leyden/commit/cc5cda558736ffeae2a4611d87dfe280b9a4eac3 8328005: Convert java/awt/im/JTextFieldTest.java applet test to main Reviewed-by: prr, abhiscxk - test/jdk/java/awt/im/JTextFieldTest.html ! test/jdk/java/awt/im/JTextFieldTest.java Changeset: e81374e0 Author: Phil Race Date: 2024-03-21 17:47:19 +0000 URL: https://git.openjdk.org/leyden/commit/e81374e0501a8201dac701824d2e29f2cedfcdff 8328560: java/awt/event/MouseEvent/ClickDuringKeypress/ClickDuringKeypress.java imports Applet Reviewed-by: azvegint, abhiscxk ! test/jdk/java/awt/event/MouseEvent/ClickDuringKeypress/ClickDuringKeypress.java Changeset: fa823bd2 Author: Phil Race Date: 2024-03-21 17:48:23 +0000 URL: https://git.openjdk.org/leyden/commit/fa823bd21c6676c67c42275efb59868200409b38 8328540: test javax/swing/JSplitPane/4885629/bug4885629.java fails on windows hidpi Reviewed-by: abhiscxk, psadhukhan ! test/jdk/javax/swing/JSplitPane/4885629/bug4885629.java Changeset: ba05c6d0 Author: Damon Nguyen Date: 2024-03-21 17:55:23 +0000 URL: https://git.openjdk.org/leyden/commit/ba05c6d0b6955a0c5110b75e709e2206961f9fec 8328368: Convert java/awt/image/multiresolution/MultiDisplayTest/MultiDisplayTest.java applet test to main Reviewed-by: azvegint, aivanov + test/jdk/java/awt/image/multiresolution/MultiDisplayTest.java - test/jdk/java/awt/image/multiresolution/MultiDisplayTest/MultiDisplayTest.html - test/jdk/java/awt/image/multiresolution/MultiDisplayTest/MultiDisplayTest.java Changeset: ab28045d Author: Viktor Klang Date: 2024-03-21 19:20:01 +0000 URL: https://git.openjdk.org/leyden/commit/ab28045d7785d948b2bce685f06043e8217961f4 8328316: Finisher cannot emit if stream is sequential and integrator returned false Reviewed-by: psandoz ! src/java.base/share/classes/java/util/stream/GathererOp.java + test/jdk/java/util/stream/GathererShortCircuitTest.java Changeset: ab183e43 Author: Phil Race Date: 2024-03-21 20:07:58 +0000 URL: https://git.openjdk.org/leyden/commit/ab183e437c18b445e9c022a4d74de818d4ccecbe 8328642: Convert applet test MouseDraggedOutCauseScrollingTest.html to main Reviewed-by: abhiscxk, azvegint - test/jdk/java/awt/List/MouseDraggedOutCauseScrollingTest/MouseDraggedOutCauseScrollingTest.html ! test/jdk/java/awt/List/MouseDraggedOutCauseScrollingTest/MouseDraggedOutCauseScrollingTest.java Changeset: 4210e507 Author: Alexey Bakhtin Date: 2024-03-21 22:28:02 +0000 URL: https://git.openjdk.org/leyden/commit/4210e507a0e65de00fab50e0584aa82cd7b3bf27 8320362: Load anchor certificates from Keychain keystore Reviewed-by: weijun, mullan ! src/java.base/macosx/classes/apple/security/AppleProvider.java ! src/java.base/macosx/classes/apple/security/KeychainStore.java ! src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m ! test/jdk/TEST.groups ! test/jdk/java/security/KeyStore/CheckMacOSKeyChainTrust.java + test/jdk/security/infra/javax/net/ssl/HttpsURLConnectionTest.java Changeset: 771f6a2f Author: Leonid Mesnik Date: 2024-03-21 22:35:25 +0000 URL: https://git.openjdk.org/leyden/commit/771f6a2f8e236e224b0e33b89f664c4bfc49e595 8327704: Update nsk/jdi tests to use driver instead of othervm Reviewed-by: sspitsyn, cjplummer ! test/hotspot/jtreg/vmTestbase/nsk/jdi/AccessWatchpointEvent/_itself_/awevent001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/AccessWatchpointEvent/_itself_/awevent001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isPackagePrivate/accipp001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isPackagePrivate/accipp001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isPackagePrivate/accipp002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isPackagePrivate/accipp002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isPrivate/isPrivate001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isPrivate/isPrivate001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isPrivate/isprivate002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isPrivate/isprivate002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isProtected/isProtected001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isProtected/isProtected001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isProtected/isprotected002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isProtected/isprotected002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isPublic/isPublic001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isPublic/isPublic001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isPublic/ispublic002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isPublic/ispublic002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isPublic/ispublic003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isPublic/ispublic003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/modifiers/modifiers001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/modifiers/modifiers001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/modifiers/modifiers002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/modifiers/modifiers002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/description/description001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/description/description001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/isValid/isvalid001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/isValid/isvalid001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/isValid/isvalid002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/isValid/isvalid002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/isValid/isvalid003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/isValid/isvalid003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/isValid/isvalid004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/isValid/isvalid004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/isValid/isvalid005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/isValid/isvalid005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/label/label001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/label/label001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/mustSpecify/mustspecify001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/mustSpecify/mustspecify001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/name/name001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/name/name001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/setValue/setvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/setValue/setvalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/setValue/setvalue002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/setValue/setvalue002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/value/value001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/value/value001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/value/value002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/value/value002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/value/value003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Argument/value/value004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValue/getvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValue/getvalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValue/getvalue002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValue/getvalue002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValue/getvalue003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValue/getvalue003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValues/getvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValues/getvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValues/getvalues002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValues/getvalues002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValues/getvalues003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValues/getvalues003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValues_ii/getvaluesii001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValues_ii/getvaluesii001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValues_ii/getvaluesii002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValues_ii/getvaluesii002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValues_ii/getvaluesii003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValues_ii/getvaluesii003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValues_ii/getvaluesii004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValues_ii/getvaluesii004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValues_ii/getvaluesii005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/getValues_ii/getvaluesii005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/length/length001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/length/length001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValue/setvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValue/setvalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValue/setvalue002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValue/setvalue002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValue/setvalue003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValue/setvalue003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValues_ilii/setvaluesilii001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValues_ilii/setvaluesilii001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValues_ilii/setvaluesilii002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValues_ilii/setvaluesilii002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValues_ilii/setvaluesilii003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValues_ilii/setvaluesilii003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValues_ilii/setvaluesilii004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValues_ilii/setvaluesilii004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValues_ilii/setvaluesilii005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValues_ilii/setvaluesilii005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValues_l/setvaluesl001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValues_l/setvaluesl001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValues_l/setvaluesl002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValues_l/setvaluesl002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValues_l/setvaluesl003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayReference/setValues_l/setvaluesl003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/componentSignature/componentsignature001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/componentSignature/componentsignature001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/componentSignature/componentsignature002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/componentSignature/componentsignature002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/componentType/componenttype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/componentType/componenttype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/componentTypeName/componenttypename001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/componentTypeName/componenttypename001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/componentTypeName/componenttypename002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/componentTypeName/componenttypename002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/AttachingConnector/attach/attach001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/AttachingConnector/attach/attach002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/AttachingConnector/attach/attach002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/AttachingConnector/attach/attach003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/AttachingConnector/attach/attach003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/AttachingConnector/attach/attach004/TestDriver.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/AttachingConnector/attach/attach004/attach004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/AttachingConnector/attachnosuspend/attachnosuspend001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc01x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc01x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc01x002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc01x002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc02x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc02x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc02x002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc02x002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc03x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc03x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc04x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc04x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc04x002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc04x002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc05x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc05x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc05x002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc05x002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc06x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc06x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc07x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc07x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc08x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc08x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc09x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc09x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc09x002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc09x002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc10x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc10x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc10x002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/hotswap/tc10x002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc01x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc01x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc03x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc03x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc04x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc04x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/singlethrd/tc01x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/singlethrd/tc01x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/singlethrd/tc01x002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/singlethrd/tc01x002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/singlethrd/tc02x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/singlethrd/tc02x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/singlethrd/tc03x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/singlethrd/tc03x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/singlethrd/tc03x002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/singlethrd/tc03x002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/singlethrd/tc03x003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/singlethrd/tc03x003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/singlethrd/tc04x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/singlethrd/tc04x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/singlethrd/tc05x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/singlethrd/tc05x001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanArgument/booleanValue/booleanvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanArgument/booleanValue/booleanvalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanArgument/booleanValue/booleanvalue002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanArgument/booleanValue/booleanvalue002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanArgument/isValid/isvalid001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanArgument/isValid/isvalid001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanArgument/isValid/isvalid002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanArgument/isValid/isvalid002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanArgument/setValue/setvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanArgument/setValue/setvalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanArgument/setValue/setvalue002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanArgument/setValue/setvalue002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanArgument/stringValueOf/stringvalueof001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanArgument/stringValueOf/stringvalueof001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanArgument/stringValueOf/stringvalueof002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanArgument/stringValueOf/stringvalueof002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanType/_itself_/booleantype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanType/_itself_/booleantype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanValue/equals/equals001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanValue/equals/equals001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanValue/equals/equals002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanValue/equals/equals002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanValue/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanValue/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanValue/value/value001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BooleanValue/value/value001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointEvent/_itself_/breakpoint001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointEvent/_itself_/breakpoint001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointEvent/_itself_/breakpoint002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointEvent/_itself_/breakpoint002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/_bounds_/filters001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/_bounds_/filters001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/location/location001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/location/location001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ByteType/_itself_/bytetype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ByteType/_itself_/bytetype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ByteValue/compareTo/compareto001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ByteValue/compareTo/compareto001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ByteValue/equals/equals001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ByteValue/equals/equals001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ByteValue/equals/equals002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ByteValue/equals/equals002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ByteValue/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ByteValue/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ByteValue/value/value001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ByteValue/value/value001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/CharType/_itself_/chartype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/CharType/_itself_/chartype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/CharValue/compareTo/compareto001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/CharValue/compareTo/compareto001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/CharValue/equals/equals001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/CharValue/equals/equals001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/CharValue/equals/equals002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/CharValue/equals/equals002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/CharValue/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/CharValue/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/CharValue/value/value001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/CharValue/value/value001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses/definedclasses001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses/definedclasses001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses/definedclasses002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses/definedclasses002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses/definedclasses003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses/definedclasses003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses/definedclasses004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses/definedclasses004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses/definedclasses005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses/definedclasses005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassLoaderReference/visibleClasses/visibleclasses001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassLoaderReference/visibleClasses/visibleclasses001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassLoaderReference/visibleClasses/visibleclasses002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassLoaderReference/visibleClasses/visibleclasses002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/reflectedType/reflectype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/reflectedType/reflectype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/reflectedType/reflectype002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/reflectedType/reflectype002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/toString/tostring001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/toString/tostring001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/referenceType/refType001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/referenceType/refType001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/thread/thread001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/thread/thread001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/_bounds_/filters001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/_bounds_/filters001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassExclusionFilter/filter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassExclusionFilter/filter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassExclusionFilter/filter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassExclusionFilter/filter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassExclusionFilter/filter003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassExclusionFilter/filter003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_rt/filter_rt001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_rt/filter_rt001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_rt/filter_rt002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_rt/filter_rt002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_rt/filter_rt003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_rt/filter_rt003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_s/filter_s001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_s/filter_s001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_s/filter_s002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_s/filter_s002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSourceNameFilter001/addSourceNameFilter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSourceNameFilter002/addSourceNameFilter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/allInterfaces/allinterfaces001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/allInterfaces/allinterfaces001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/allInterfaces/allinterfaces002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/allInterfaces/allinterfaces002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/concreteMethodByName/method001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/concreteMethodByName/method001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/concreteMethodByName/method002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/concreteMethodByName/method002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/interfaces/interfaces001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/interfaces/interfaces001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/interfaces/interfaces002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/interfaces/interfaces002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod007/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod008.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod008/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod009.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod009/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod010.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod010/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod012.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod012/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod013.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod013/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod014.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod014/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod015.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod015/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/isEnum/isenum001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/isEnum/isenum001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance007/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance008.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance008/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance009.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance009/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/setValue/setvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/setValue/setvalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/setValue/setvalue002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/setValue/setvalue002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/setValue/setvalue003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/setValue/setvalue003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/setValue/setvalue004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/setValue/setvalue004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/setValue/setvalue005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/setValue/setvalue005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/setValue/setvalue006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/setValue/setvalue006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/setValue/setvalue007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/setValue/setvalue007/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/setValue/setvalue008.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/setValue/setvalue008/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/subclasses/subclasses001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/subclasses/subclasses001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/subclasses/subclasses002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/subclasses/subclasses002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/superclass/superclass001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/superclass/superclass001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/superclass/superclass002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/superclass/superclass002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadEvent/className/classname001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadEvent/className/classname001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadEvent/classSignature/signature001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadEvent/classSignature/signature001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadRequest/_bounds_/filters001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadRequest/_bounds_/filters001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadRequest/addClassExclusionFilter/exclfilter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadRequest/addClassExclusionFilter/exclfilter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadRequest/addClassExclusionFilter/exclfilter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadRequest/addClassFilter/filter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadRequest/addClassFilter/filter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadRequest/addClassFilter/filter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Connector/_bounds_/bounds001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Connector/_bounds_/bounds001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Connector/defaultArguments/defaultArguments001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Connector/defaultArguments/defaultArguments001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Connector/defaultArguments/defaultArguments002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Connector/defaultArguments/defaultArguments002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Connector/defaultArguments/defaultArguments003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Connector/defaultArguments/defaultArguments003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Connector/description/description001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Connector/description/description001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Connector/name/name001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Connector/name/name001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Connector/toString/tostring001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Connector/toString/tostring001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Connector/transport/transport001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Connector/transport/transport001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ConstantField/values001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ConstantField/values001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/DoubleType/_itself_/doubletype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/DoubleType/_itself_/doubletype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/DoubleValue/compareTo/compareto001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/DoubleValue/compareTo/compareto001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/DoubleValue/equals/equals001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/DoubleValue/equals/equals001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/DoubleValue/equals/equals002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/DoubleValue/equals/equals002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/DoubleValue/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/DoubleValue/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/DoubleValue/value/value001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/DoubleValue/value/value001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/_itself_/event001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/_itself_/event001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/_itself_/event002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/_itself_/event002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/equals/equals001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/equals/equals001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/request/request001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/request/request001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventIterator/nextEvent/nextevent001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventIterator/nextEvent/nextevent001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove/remove001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove/remove001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove/remove002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove/remove002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove/remove003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove/remove003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove/remove004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove/remove004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/_bounds_/eventrequest001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/_bounds_/eventrequest001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/addCountFilter/addcountfilter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/addCountFilter/addcountfilter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/disable/disable001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/disable/disable001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/disable/disable002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/disable/disable002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/disable/disable003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/disable/disable003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/enable/enable001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/enable/enable001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/enable/enable002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/enable/enable002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/getProperty/getproperty001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/getProperty/getproperty001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/isEnabled/isenabled001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/isEnabled/isenabled001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/putProperty/putproperty001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/putProperty/putproperty001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setSuspendPolicy/setsuspendpolicy001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setSuspendPolicy/setsuspendpolicy001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/suspendPolicy/suspendpolicy001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/suspendPolicy/suspendpolicy001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/_bounds_/requests001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/_bounds_/requests001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/accessWatchpointRequests/accwtchpreq001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/accessWatchpointRequests/accwtchpreq001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/accessWatchpointRequests/accwtchpreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/accessWatchpointRequests/accwtchpreq002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/breakpointRequests/breakpreq001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/breakpointRequests/breakpreq001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/breakpointRequests/breakpreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/breakpointRequests/breakpreq002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/classPrepareRequests/clsprepreq001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/classPrepareRequests/clsprepreq001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/classPrepareRequests/clsprepreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/classPrepareRequests/clsprepreq002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/classUnloadRequests/clsunlreq001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/classUnloadRequests/clsunlreq001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/classUnloadRequests/clsunlreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/classUnloadRequests/clsunlreq002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createAccessWatchpointRequest/craccwtchpreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createAccessWatchpointRequest/craccwtchpreq002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createAccessWatchpointRequest/craccwtchpreq003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createAccessWatchpointRequest/craccwtchpreq003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createBreakpointRequest/crbreakpreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createBreakpointRequest/crbreakpreq002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createBreakpointRequest/crbreakpreq003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createBreakpointRequest/crbreakpreq003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createClassPrepareRequest/cpreg001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createClassPrepareRequest/cpreg001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createClassUnloadRequest/cureg001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createClassUnloadRequest/cureg001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createExceptionRequest/crexreq009.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createExceptionRequest/crexreq009/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createExceptionRequest/crexreq010.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createExceptionRequest/crexreq010/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createMethodEntryRequest/menreg001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createMethodEntryRequest/menreg001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createMethodExitRequest/mexreg001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createMethodExitRequest/mexreg001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createModificationWatchpointRequest/crmodwtchpreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createModificationWatchpointRequest/crmodwtchpreq002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createModificationWatchpointRequest/crmodwtchpreq003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createModificationWatchpointRequest/crmodwtchpreq003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq007/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq008.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq008/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq009.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq009/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq010.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq010/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createThreadDeathRequest/tdreg001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createThreadDeathRequest/tdreg001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createThreadStartRequest/tsreg001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createThreadStartRequest/tsreg001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createVMDeathRequest/vmdreg001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createVMDeathRequest/vmdreg001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/deleteAllBreakpoints/delallbreakp002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/deleteAllBreakpoints/delallbreakp002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/deleteEventRequest/delevtreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/deleteEventRequest/delevtreq002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/deleteEventRequest/delevtreq003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/deleteEventRequest/delevtreq003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/deleteEventRequests/delevtreqs002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/deleteEventRequests/delevtreqs002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/exceptionRequests/excreq001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/exceptionRequests/excreq001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/exceptionRequests/excreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/exceptionRequests/excreq002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/methodEntryRequests/methentreq001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/methodEntryRequests/methentreq001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/methodEntryRequests/methentreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/methodEntryRequests/methentreq002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/methodExitRequests/methexitreq001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/methodExitRequests/methexitreq001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/methodExitRequests/methexitreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/methodExitRequests/methexitreq002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/modificationWatchpointRequests/modwtchpreq001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/modificationWatchpointRequests/modwtchpreq001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/modificationWatchpointRequests/modwtchpreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/modificationWatchpointRequests/modwtchpreq002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/stepRequests/stepreq001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/stepRequests/stepreq001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/stepRequests/stepreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/stepRequests/stepreq002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/threadDeathRequests/thrdeathreq001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/threadDeathRequests/thrdeathreq001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/threadDeathRequests/thrdeathreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/threadDeathRequests/thrdeathreq002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/threadStartRequests/thrstartreq001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/threadStartRequests/thrstartreq001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/threadStartRequests/thrstartreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/threadStartRequests/thrstartreq002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/vmDeathRequests/vmdeathreq001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/vmDeathRequests/vmdeathreq001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/eventIterator/eventiterator001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/eventIterator/eventiterator001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/eventIterator/eventiterator002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/eventIterator/eventiterator002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/eventIterator/eventiterator003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/eventIterator/eventiterator003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/eventIterator/eventiterator004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/eventIterator/eventiterator004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume007/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume008.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume008/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume009.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume009/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume010.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume010/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume011.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume011/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume012.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume012/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume013.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume013/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy007/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy009.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy009/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy010.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy010/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy011.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy011/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy012.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy012/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy013.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy013/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy014.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy014/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy015.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy015/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy016.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy016/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy017.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy017/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy018.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy018/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/toString/tostring001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/toString/tostring001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/virtualMachine/virtualmachine001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/virtualMachine/virtualmachine001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent007/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/catchLocation/location001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/catchLocation/location001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/catchLocation/location002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/catchLocation/location002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/exception/exception001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/exception/exception001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/_bounds_/filters001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/_bounds_/filters001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassExclusionFilter/filter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassExclusionFilter/filter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassExclusionFilter/filter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassExclusionFilter/filter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_rt/filter_rt001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_rt/filter_rt001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_rt/filter_rt002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_rt/filter_rt002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_rt/filter_rt003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_rt/filter_rt003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_s/filter_s001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_s/filter_s001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_s/filter_s002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_s/filter_s002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addThreadFilter/threadfilter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addThreadFilter/threadfilter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addThreadFilter/threadfilter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addThreadFilter/threadfilter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addThreadFilter/threadfilter003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addThreadFilter/threadfilter003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addThreadFilter/threadfilter004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addThreadFilter/threadfilter004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/exception/exception001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/exception/exception001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/notifyCaught/notifycaught001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/notifyCaught/notifycaught001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/notifyUncaught/notifyuncaught001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/notifyUncaught/notifyuncaught001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/equals/equals001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/equals/equals001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/equals/equals002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/equals/equals002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/equals/equals003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/equals/equals003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/equals/equals005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/equals/equals005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/isEnumConstant/isenumconstant001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/isEnumConstant/isenumconstant001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/isTransient/istrans001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/isTransient/istrans001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/isVolatile/isvol001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/isVolatile/isvol001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/type/type001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/type/type001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/type/type002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/type/type002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/type/type003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/type/type003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/type/type004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/type/type004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/typeName/typename001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/typeName/typename001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/typeName/typename002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Field/typeName/typename002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/FloatType/_itself_/floattype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/FloatType/_itself_/floattype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/FloatValue/compareTo/compareto001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/FloatValue/compareTo/compareto001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/FloatValue/equals/equals001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/FloatValue/equals/equals001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/FloatValue/equals/equals002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/FloatValue/equals/equals002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/FloatValue/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/FloatValue/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/FloatValue/value/value001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/FloatValue/value/value001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/events/events001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerArgument/intValue/intvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerArgument/intValue/intvalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerArgument/intValue/intvalue002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerArgument/intValue/intvalue002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerArgument/isValid/isvalid001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerArgument/isValid/isvalid001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerArgument/isValid/isvalid002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerArgument/isValid/isvalid002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerArgument/isValid/isvalid003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerArgument/isValid/isvalid003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerArgument/max/max001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerArgument/max/max001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerArgument/min/min001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerArgument/min/min001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerArgument/setValue/setvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerArgument/setValue/setvalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerArgument/stringValueOf/stringvalueof001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerArgument/stringValueOf/stringvalueof001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerType/_itself_/integertype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerType/_itself_/integertype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerValue/compareTo/compareto001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerValue/compareTo/compareto001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerValue/equals/equals001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerValue/equals/equals001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerValue/equals/equals002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerValue/equals/equals002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerValue/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerValue/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerValue/value/value001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/IntegerValue/value/value001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/InterfaceType/implementors/implementors001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/InterfaceType/implementors/implementors001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/InterfaceType/subinterfaces/subinterfaces001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/InterfaceType/subinterfaces/subinterfaces001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/InterfaceType/superinterfaces/superinterfaces001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/InterfaceType/superinterfaces/superinterfaces001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LaunchingConnector/launch/launch001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LaunchingConnector/launch/launch002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LaunchingConnector/launch/launch003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LaunchingConnector/launch/launch004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LaunchingConnector/launchnosuspend/launchnosuspend001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/accept/accept001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/accept/accept002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/listennosuspend/listennosuspend001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/startListening/startlis001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/startListening/startlis002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/stopListening/stoplis001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/stopListening/stoplis001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/stopListening/stoplis002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/stopListening/stoplis002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/supportsMultipleConnections/supportsmultipleconnections001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/supportsMultipleConnections/supportsmultipleconnections001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/equals/equals001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/equals/equals001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/genericSignature/gensignature001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/genericSignature/gensignature001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/isArgument/isargument001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/isArgument/isargument001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/isVisible/isvisible001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/isVisible/isvisible001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/name/name001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/name/name001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/signature/signature001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/signature/signature001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/toString/tostring001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/toString/tostring001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/type/type001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/type/type001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/type/type002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/type/type002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/typeName/typename001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/typeName/typename001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/typeName/typename002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/typeName/typename002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Locatable/location/location001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Locatable/location/location001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Locatable/location/location002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Locatable/location/location002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Locatable/location/location003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Locatable/location/location003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Locatable/location/location004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Locatable/location/location004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Locatable/location/location005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Locatable/location/location005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Locatable/location/location006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Locatable/location/location006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocatableEvent/thread/thread001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocatableEvent/thread/thread001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/codeIndex/codeindex001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/codeIndex/codeindex001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/declaringType/declaringtype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/declaringType/declaringtype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/equals/equals001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/equals/equals001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/lineNumber/linenumber001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/lineNumber/linenumber001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/lineNumber_s/lineNumber_s002/lineNumber_s002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/lineNumber_s/linenumber_s001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/lineNumber_s/linenumber_s001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/method/method001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/method/method001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/sourceName/sourcename001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/sourceName/sourcename001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/sourceName_s/sourceName_s002/sourceName_s002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/sourceName_s/sourcename_s001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/sourceName_s/sourcename_s001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/sourcePath/sourcepath001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/sourcePath/sourcepath001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/sourcePath_s/sourcePath_s002/sourcePath_s002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/sourcePath_s/sourcepath_s001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Location/sourcePath_s/sourcepath_s001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LongType/_itself_/longtype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LongType/_itself_/longtype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LongValue/compareTo/compareto001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LongValue/compareTo/compareto001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LongValue/equals/equals001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LongValue/equals/equals001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LongValue/equals/equals002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LongValue/equals/equals002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LongValue/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LongValue/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LongValue/value/value001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LongValue/value/value001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/_bounds_/bounds001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/_bounds_/bounds001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/allLineLocations/alllinelocations001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/allLineLocations/alllinelocations001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/allLineLocations/alllinelocations002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/allLineLocations/alllinelocations002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/allLineLocations_ss/allLineLocations_ss002/allLineLocations_ss002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/allLineLocations_ss/allLineLocations_ss003/allLineLocations_ss003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/allLineLocations_ss/alllinelocations_ss001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/allLineLocations_ss/alllinelocations_ss001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/argumentTypeNames/argumenttypenames001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/argumentTypeNames/argumenttypenames001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/argumentTypeNames/argumenttypenames002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/argumentTypeNames/argumenttypenames002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/argumentTypeNames/argumenttypenames003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/argumentTypeNames/argumenttypenames003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/argumentTypes/argumenttypes001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/argumentTypes/argumenttypes001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/argumentTypes/argumenttypes002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/argumentTypes/argumenttypes002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/arguments/arguments001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/arguments/arguments001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/arguments/arguments002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/arguments/arguments002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/arguments/arguments003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/arguments/arguments003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/bytecodes/bytecodes001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/bytecodes/bytecodes001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/equals/equals001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/equals/equals001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isAbstract/isabstract001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isAbstract/isabstract001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isBridge/isbridge001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isBridge/isbridge001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isConstructor/isconstructor001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isConstructor/isconstructor001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isNative/isnative001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isNative/isnative001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isObsolete/isobsolete001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isObsolete/isobsolete001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isObsolete/isobsolete002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isObsolete/isobsolete002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isObsolete/isobsolete003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isObsolete/isobsolete003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isStaticInitializer/isstinitializer001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isStaticInitializer/isstinitializer001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isSynchronized/issynchronized001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isSynchronized/issynchronized001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isVarArgs/isvarargs001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/isVarArgs/isvarargs001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/locationOfCodeIndex/locationofcodeindex001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/locationOfCodeIndex/locationofcodeindex001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/locationsOfLine/locationsofline001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/locationsOfLine/locationsofline001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/locationsOfLine_ssi/locationsOfLine_ssi002/locationsOfLine_ssi002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/locationsOfLine_ssi/locationsOfLine_ssi003/locationsOfLine_ssi003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/locationsOfLine_ssi/locationsofline_ssi001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/locationsOfLine_ssi/locationsofline_ssi001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/returnType/returntype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/returnType/returntype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/returnType/returntype002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/returnType/returntype002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/returnType/returntype003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/returnType/returntype003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/returnTypeNames/returntypenames001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/returnTypeNames/returntypenames001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/returnTypeNames/returntypenames002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/returnTypeNames/returntypenames002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/returnTypeNames/returntypenames003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/returnTypeNames/returntypenames003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/variables/variables001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/variables/variables001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/variables/variables002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/variables/variables002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/variablesByName/variablesbyname001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/variablesByName/variablesbyname001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/variablesByName/variablesbyname002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Method/variablesByName/variablesbyname002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryEvent/method/method001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryEvent/method/method001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryEvent/method/method002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryEvent/method/method002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/_bounds_/filters001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/_bounds_/filters001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassExclusionFilter/filter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassExclusionFilter/filter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassExclusionFilter/filter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassExclusionFilter/filter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_s/filter_s001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_s/filter_s001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_s/filter_s002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_s/filter_s002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addThreadFilter/threadfilter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addThreadFilter/threadfilter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addThreadFilter/threadfilter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addThreadFilter/threadfilter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addThreadFilter/threadfilter003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addThreadFilter/threadfilter003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addThreadFilter/threadfilter004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addThreadFilter/threadfilter004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitEvent/_itself_/methodexit001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitEvent/_itself_/methodexit001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitEvent/method/method001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitEvent/method/method001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitEvent/method/method002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitEvent/method/method002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitEvent/returnValue/returnValue001/returnValue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitEvent/returnValue/returnValue002/returnValue002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitEvent/returnValue/returnValue003/returnValue003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitEvent/returnValue/returnValue004/returnValue004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/_bounds_/filters001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/_bounds_/filters001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_rt/filter_rt001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_rt/filter_rt001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_rt/filter_rt002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_rt/filter_rt002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_rt/filter_rt003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_rt/filter_rt003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_s/filter_s001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_s/filter_s001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_s/filter_s002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_s/filter_s002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Mirror/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Mirror/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Mirror/toString/tostring001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Mirror/toString/tostring001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Mirror/virtualMachine/virtualmachine001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Mirror/virtualMachine/virtualmachine001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ModificationWatchpointEvent/_itself_/mwevent001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ModificationWatchpointEvent/_itself_/mwevent001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ModificationWatchpointEvent/valueToBe/valuetobe001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ModificationWatchpointEvent/valueToBe/valuetobe001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ModificationWatchpointEvent/valueToBe/valuetobe002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ModificationWatchpointEvent/valueToBe/valuetobe002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MonitorWaitRequest/MonitorWaitRequest001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MonitorWaitRequest/MonitorWaitRequest002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MonitorWaitRequest/addClassExclusionFilter/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MonitorWaitRequest/addClassFilter_ClassName/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MonitorWaitRequest/addClassFilter_ReferenceType/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MonitorWaitRequest/addInstanceFilter/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MonitorWaitRequest/addThreadFilter/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MonitorWaitedRequest/MonitorWaitedRequest001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MonitorWaitedRequest/MonitorWaitedRequest002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MonitorWaitedRequest/addClassExclusionFilter/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MonitorWaitedRequest/addClassFilter_ClassName/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MonitorWaitedRequest/addClassFilter_ReferenceType/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MonitorWaitedRequest/addInstanceFilter/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/MonitorWaitedRequest/addThreadFilter/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/_bounds_/bounds001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/_bounds_/bounds001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/_bounds_/bounds002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/_bounds_/bounds002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/_bounds_/bounds003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/_bounds_/bounds003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/disableCollection/disablecollection001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/disableCollection/disablecollection001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/disableCollection/disablecollection002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/disableCollection/disablecollection002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/entryCount/entrycount001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/entryCount/entrycount001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/entryCount/entrycount002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/entryCount/entrycount002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/equals/equals001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/equals/equals001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValue/getvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValue/getvalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValue/getvalue002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValue/getvalue002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValue/getvalue003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValue/getvalue003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValue/getvalue004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValue/getvalue004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValues/getvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValues/getvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValues/getvalues002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValues/getvalues002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValues/getvalues003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValues/getvalues003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod007/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod008.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod008/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod009.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod009/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod010.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod010/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod011.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod011/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod012.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod012/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod013.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod013/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod014.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod014/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/isCollected/iscollected001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/isCollected/iscollected001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referenceType/referencetype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referenceType/referencetype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referenceType/referencetype002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referenceType/referencetype002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referenceType/referencetype003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referenceType/referencetype003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referenceType/referencetype004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referenceType/referencetype004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referenceType/referencetype005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referenceType/referencetype005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referenceType/referencetype006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referenceType/referencetype006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referenceType/referencetype007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referenceType/referencetype007/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects001/referringObjects001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects003/referringObjects003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects004/referringObjects004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/uniqueID/uniqueid001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/uniqueID/uniqueid001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/waitingThreads/waitingthreads001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/waitingThreads/waitingthreads001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/waitingThreads/waitingthreads002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/waitingThreads/waitingthreads002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/waitingThreads/waitingthreads003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/waitingThreads/waitingthreads003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/waitingThreads/waitingthreads004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/waitingThreads/waitingthreads004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PathSearchingVirtualMachine/baseDirectory/directory001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PathSearchingVirtualMachine/baseDirectory/directory001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PathSearchingVirtualMachine/bootClassPath/bootpath001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PathSearchingVirtualMachine/bootClassPath/bootpath001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PathSearchingVirtualMachine/classPath/classpath001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PathSearchingVirtualMachine/classPath/classpath001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveType/_itself_/primitivetype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveType/_itself_/primitivetype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveValue/booleanValue/booleanvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveValue/booleanValue/booleanvalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveValue/byteValue/bytevalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveValue/byteValue/bytevalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveValue/charValue/charvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveValue/charValue/charvalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveValue/doubleValue/doublevalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveValue/doubleValue/doublevalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveValue/doubleValue/doublevalue002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveValue/doubleValue/doublevalue002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveValue/floatValue/floatvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveValue/floatValue/floatvalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveValue/intValue/intvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveValue/intValue/intvalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveValue/longValue/longvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveValue/longValue/longvalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveValue/shortValue/shortvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/PrimitiveValue/shortValue/shortvalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/_bounds_/bounds001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/_bounds_/bounds001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/_bounds_/bounds002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/_bounds_/bounds002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allFields/allfields001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allFields/allfields001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allFields/allfields002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allFields/allfields002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allFields/allfields003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allFields/allfields003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allFields/allfields004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allFields/allfields004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allFields/allfields005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allFields/allfields005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allFields/allfields006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allFields/allfields006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allLineLocations/alllinelocations001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allLineLocations/alllinelocations001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allLineLocations/alllinelocations002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allLineLocations/alllinelocations002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allLineLocations_ss/allLineLocations_ss003/allLineLocations_ss003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allLineLocations_ss/allLineLocations_ss004/allLineLocations_ss004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allLineLocations_ss/alllinelocations_ss001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allLineLocations_ss/alllinelocations_ss001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allLineLocations_ss/alllinelocations_ss002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allLineLocations_ss/alllinelocations_ss002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allMethods/allmethods001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allMethods/allmethods001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allMethods/allmethods002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allMethods/allmethods002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allMethods/allmethods003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allMethods/allmethods003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allMethods/allmethods004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allMethods/allmethods004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allMethods/allmethods005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allMethods/allmethods005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allMethods/allmethods006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allMethods/allmethods006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/availableStrata/availableStrata002/availableStrata002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/availableStrata/availablestrata001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/availableStrata/availablestrata001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/classLoader/classloader001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/classLoader/classloader001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/classObject/classobj001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/classObject/classobj001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/classObject/classobj002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/classObject/classobj002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/classObject/classobj003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/classObject/classobj003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/defaultStratum/defaultStratum002/defaultStratum002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/defaultStratum/defaultStratum003/defaultStratum003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/defaultStratum/defaultStratum004/defaultStratum004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/defaultStratum/defaultstratum001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/defaultStratum/defaultstratum001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/equals/equals001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/equals/equals001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/equals/equals002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/equals/equals002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/failedToInitialize/failedToInitialize001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/failedToInitialize/failedToInitialize001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/failedToInitialize/failedtoinit002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/failedToInitialize/failedtoinit002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fieldByName/fieldbyname001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fieldByName/fieldbyname001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fieldByName/fieldbyname002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fieldByName/fieldbyname002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fieldByName/fieldbyname003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fieldByName/fieldbyname003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fields/fields001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fields/fields001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fields/fields002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fields/fields002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fields/fields003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fields/fields003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fields/fields004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fields/fields004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fields/fields005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fields/fields005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fields/fields006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fields/fields006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/genericSignature/genericSignature001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/genericSignature/genericSignature001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/genericSignature/genericSignature002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/genericSignature/genericSignature002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/getValue/getvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/getValue/getvalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/getValue/getvalue002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/getValue/getvalue002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/getValue/getvalue003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/getValue/getvalue003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/getValue/getvalue004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/getValue/getvalue004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/getValue/getvalue005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/getValue/getvalue005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/getValues/getvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/getValues/getvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/getValues/getvalues002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/getValues/getvalues002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/getValues/getvalues003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/getValues/getvalues003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/hashCode/hashcode002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/hashCode/hashcode002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/instances/instances001/instances001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/instances/instances003/instances003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/instances/instances005/instances005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isAbstract/isAbstract001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isAbstract/isAbstract001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isAbstract/isabstract002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isAbstract/isabstract002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isAbstract/isabstract003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isAbstract/isabstract003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isFinal/isfinal001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isFinal/isfinal001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isFinal/isfinal002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isFinal/isfinal002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isInitialized/isinit001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isInitialized/isinit001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isInitialized/isinit002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isInitialized/isinit002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isInitialized/isinit003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isInitialized/isinit003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isPrepared/isprepared001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isPrepared/isprepared001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isPrepared/isprepared002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isPrepared/isprepared002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isStatic/isstatic001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isStatic/isstatic001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isStatic/isstatic002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isStatic/isstatic002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isVerified/isVerified001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isVerified/isVerified001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isVerified/isverified002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isVerified/isverified002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isVerified/isverified003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isVerified/isverified003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/locationsOfLine_i/locationsofline_i001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/locationsOfLine_i/locationsofline_i001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/locationsOfLine_i/locationsofline_i002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/locationsOfLine_i/locationsofline_i002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/locationsOfLine_ssi/locationsOfLine_ssi003/locationsOfLine_ssi003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/locationsOfLine_ssi/locationsOfLine_ssi004/locationsOfLine_ssi004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/locationsOfLine_ssi/locationsofline_ssi001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/locationsOfLine_ssi/locationsofline_ssi001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/locationsOfLine_ssi/locationsofline_ssi002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/locationsOfLine_ssi/locationsofline_ssi002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methods/methods001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methods/methods001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methods/methods002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methods/methods002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methods/methods003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methods/methods003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methods/methods004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methods/methods004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methods/methods005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methods/methods005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methods/methods006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methods/methods006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methodsByName_s/methbyname_s001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methodsByName_s/methbyname_s001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methodsByName_s/methbyname_s002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methodsByName_s/methbyname_s002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methodsByName_s/methbyname_s003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methodsByName_s/methbyname_s003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methodsByName_s/methbyname_s004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methodsByName_s/methbyname_s004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methodsByName_ss/methbyname_ss001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methodsByName_ss/methbyname_ss001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methodsByName_ss/methbyname_ss002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methodsByName_ss/methbyname_ss002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methodsByName_ss/methbyname_ss003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methodsByName_ss/methbyname_ss003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/name/name001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/name/name001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/name/name002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/name/name002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/nestedTypes/nestedtypes001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/nestedTypes/nestedtypes001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/nestedTypes/nestedtypes002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/nestedTypes/nestedtypes002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceDebugExtension/srcdebugx001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceDebugExtension/srcdebugx001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceDebugExtension/srcdebugx002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceDebugExtension/srcdebugx002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceName/sourcename001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceName/sourcename001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceName/sourcename002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceName/sourcename002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceName/sourcename003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceName/sourcename003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceName/sourcename004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceName/sourcename004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceNames/sourceNames003/sourceNames003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceNames/sourcenames001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceNames/sourcenames001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceNames/sourcenames002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceNames/sourcenames002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourcePaths/sourcePaths003/sourcePaths003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourcePaths/sourcepaths001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourcePaths/sourcepaths001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourcePaths/sourcepaths002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourcePaths/sourcepaths002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleFields/visibfield001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleFields/visibfield001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleFields/visibfield002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleFields/visibfield002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleFields/visibfield003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleFields/visibfield003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleFields/visibfield004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleFields/visibfield004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleFields/visibfield005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleFields/visibfield005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleFields/visibfield006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleFields/visibfield006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod007/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Scenarios/invokeMethod/popframes001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Scenarios/invokeMethod/popframes001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Scenarios/invokeMethod/redefineclasses001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Scenarios/invokeMethod/redefineclasses001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/SelectedArgument/choices/choices001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/SelectedArgument/choices/choices001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/SelectedArgument/isValid/isvalid001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/SelectedArgument/isValid/isvalid001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/SelectedArgument/isValid/isvalid002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/SelectedArgument/isValid/isvalid002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ShortType/_itself_/shorttype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ShortType/_itself_/shorttype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ShortValue/compareTo/compareto001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ShortValue/compareTo/compareto001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ShortValue/equals/equals001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ShortValue/equals/equals001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ShortValue/equals/equals002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ShortValue/equals/equals002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ShortValue/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ShortValue/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ShortValue/value/value001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ShortValue/value/value001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/_bounds_/bounds001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/_bounds_/bounds001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/_bounds_/bounds002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/_bounds_/bounds002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getArgumentValues/getArgumentValues001/getArgumentValues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getArgumentValues/getArgumentValues002/getArgumentValues002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getArgumentValues/getArgumentValues003/getArgumentValues003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValue/getvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValue/getvalue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValue/getvalue002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValue/getvalue002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValue/getvalue003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValue/getvalue003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValues/getvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValues/getvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValues/getvalues002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValues/getvalues002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValues/getvalues003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValues/getvalues003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/location/location001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/location/location001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue001/setvalue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue002/setvalue002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue003/setvalue003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue004/setvalue004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue005/setvalue005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue006/setvalue006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/thisObject/thisobject001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/thisObject/thisobject001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/thisObject/thisobject002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/thisObject/thisobject002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/thread/thread001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/thread/thread001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/toString/tostring001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/toString/tostring001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariableByName/visiblevarbyname001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariableByName/visiblevarbyname001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariableByName/visiblevarbyname002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariableByName/visiblevarbyname002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariables/visiblevariables001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariables/visiblevariables001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariables/visiblevariables002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariables/visiblevariables002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepEvent/_itself_/stepEvent003/stepEvent003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepEvent/_itself_/stepEvent004/stepEvent004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepEvent/_itself_/stepevent001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepEvent/_itself_/stepevent001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepEvent/_itself_/stepevent002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepEvent/_itself_/stepevent002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/_bounds_/filters001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/_bounds_/filters001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassExclusionFilter/filter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassExclusionFilter/filter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassExclusionFilter/filter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassExclusionFilter/filter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt/filter_rt001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt/filter_rt001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt/filter_rt002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt/filter_rt002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt/filter_rt003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt/filter_rt003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_s/filter_s001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_s/filter_s001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_s/filter_s002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_s/filter_s002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/depth/depth001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/depth/depth001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/depth/depth002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/depth/depth002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/depth/depth003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/depth/depth003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/size/size001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/size/size001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/size/size002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/size/size002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/thread/thread001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/thread/thread001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StringArgument/isValid/isvalid001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StringArgument/isValid/isvalid001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StringArgument/isValid/isvalid002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StringArgument/isValid/isvalid002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StringArgument/isValid/isvalid003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StringArgument/isValid/isvalid003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StringReference/value/value001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StringReference/value/value001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathEvent/thread/thread001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathEvent/thread/thread001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadGroupReference/name/name001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadGroupReference/name/name001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadGroupReference/parent/parent001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadGroupReference/parent/parent001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadGroupReference/resume/resume001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadGroupReference/resume/resume001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadGroupReference/suspend/suspend001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadGroupReference/suspend/suspend001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadGroupReference/threadGroups/threadgroups001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadGroupReference/threadGroups/threadgroups001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadGroupReference/threads/threads001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadGroupReference/threads/threads001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadGroupReference/toString/tostring001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadGroupReference/toString/tostring001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/_bounds_/bounds001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/_bounds_/bounds001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/currentContendedMonitor/currentcm001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/currentContendedMonitor/currentcm001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn001/forceEarlyReturn001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn003/forceEarlyReturn003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn004/forceEarlyReturn004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn005/forceEarlyReturn005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn007/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn008/forceEarlyReturn008.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn009/forceEarlyReturn009.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn010/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn011/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn012/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn013/forceEarlyReturn013.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn014/forceEarlyReturn014.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn015/forceEarlyReturn015.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frame/frame001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frame/frame001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frameCount/framecount001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frameCount/framecount001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frames/frames001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frames/frames001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frames_ii/frames_ii001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frames_ii/frames_ii001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frames_ii/frames_ii002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frames_ii/frames_ii002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isAtBreakpoint/isatbreakpoint001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isAtBreakpoint/isatbreakpoint001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/name/name001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/name/name001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/ownedMonitors/ownedmonitors001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/ownedMonitors/ownedmonitors001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/ownedMonitors/ownedmonitors002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/ownedMonitors/ownedmonitors002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/ownedMonitorsAndFrames/ownedMonitorsAndFrames001/ownedMonitorsAndFrames001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/ownedMonitorsAndFrames/ownedMonitorsAndFrames002/ownedMonitorsAndFrames002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/ownedMonitorsAndFrames/ownedMonitorsAndFrames003/ownedMonitorsAndFrames003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/ownedMonitorsAndFrames/ownedMonitorsAndFrames004/ownedMonitorsAndFrames004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/ownedMonitorsAndFrames/ownedMonitorsAndFrames005/ownedMonitorsAndFrames005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/ownedMonitorsAndFrames/ownedMonitorsAndFrames006/ownedMonitorsAndFrames006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/ownedMonitorsAndFrames/ownedMonitorsAndFrames007/ownedMonitorsAndFrames007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/ownedMonitorsAndFrames/ownedMonitorsAndFrames009/ownedMonitorsAndFrames009.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes007/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/status/status003/status003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/status/status004/status004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/status/status005/status005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/status/status006/status006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/status/status007/status007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/status/status008/status008.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/suspend/suspend001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/suspendCount/suspendcount001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/suspendCount/suspendcount001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/threadGroup/threadgroup001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/threadGroup/threadgroup001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartEvent/thread/thread001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartEvent/thread/thread001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Transport/name/name001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Transport/name/name001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Type/hashCode/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Type/hashCode/hashcode001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Type/name/name001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Type/name/name001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Type/name/name002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Type/name/name002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Type/name/name003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Type/name/name003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Type/signature/signature001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Type/signature/signature001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Type/signature/signature002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Type/signature/signature002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Type/signature/signature003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Type/signature/signature003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/declaringType/decltype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/declaringType/decltype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/declaringType/decltype002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/declaringType/decltype002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/declaringType/decltype003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/declaringType/decltype003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/declaringType/decltype004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/declaringType/decltype004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/declaringType/decltype005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/declaringType/decltype005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/declaringType/decltype006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/declaringType/decltype006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/declaringType/decltype007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/declaringType/decltype007/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/declaringType/decltype008.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/declaringType/decltype008/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/declaringType/decltype009.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/declaringType/decltype009/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/genericSignature/genericSignature001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/genericSignature/genericSignature001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/genericSignature/genericSignature002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/genericSignature/genericSignature002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isFinal/isfinal001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isFinal/isfinal001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isFinal/isfinal002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isFinal/isfinal002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isFinal/isfinal003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isFinal/isfinal003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isFinal/isfinal004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isFinal/isfinal004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isPackagePrivate/ispackageprivate001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isPackagePrivate/ispackageprivate001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isPackagePrivate/ispackageprivate002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isPackagePrivate/ispackageprivate002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isPrivate/isprivate001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isPrivate/isprivate001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isPrivate/isprivate002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isPrivate/isprivate002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isProtected/isprotected001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isProtected/isprotected001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isProtected/isprotected002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isProtected/isprotected002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isPublic/ispublic001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isPublic/ispublic001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isPublic/ispublic002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isPublic/ispublic002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isStatic/isstatic001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isStatic/isstatic001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isStatic/isstatic002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isStatic/isstatic002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isStatic/isstatic003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isStatic/isstatic003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isStatic/isstatic004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isStatic/isstatic004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/name/name001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/name/name001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/name/name002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/name/name002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/name/name003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/name/name003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/signature/sign001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/signature/sign001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/signature/sign002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/signature/sign002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/signature/sign003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/signature/sign003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMCannotBeModifiedEx/_itself_/canntbemod001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMCannotBeModifiedEx/_itself_/canntbemod001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMDeathEvent/_itself_/vmdeath001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMDeathEvent/_itself_/vmdeath001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMDeathEvent/_itself_/vmdeath002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMDeathEvent/_itself_/vmdeath002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMDeathEvent/_itself_/vmdeath003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMDeathEvent/_itself_/vmdeath003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMDisconnectEvent/_itself_/disconnect001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMDisconnectEvent/_itself_/disconnect001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMDisconnectEvent/_itself_/disconnect002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMDisconnectEvent/_itself_/disconnect002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMDisconnectEvent/_itself_/disconnect003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMDisconnectEvent/_itself_/disconnect003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMStartEvent/thread/thread001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMStartEvent/thread/thread001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Value/_itself_/value001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Value/_itself_/value001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Value/type/type001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Value/type/type001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Value/type/type002/type002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Value/type/type003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Value/type/type003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/allClasses/allclasses001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/allClasses/allclasses001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/allClasses/allclasses002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/allClasses/allclasses002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/allThreads/allthreads001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/allThreads/allthreads001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canAddMethod/canaddmethod001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canAddMethod/canaddmethod001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canBeModified/canbemodified001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canBeModified/canbemodified001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetBytecodes/cangetbytecodes001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetBytecodes/cangetbytecodes001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetCurrentContendedMonitor/cangccm001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetCurrentContendedMonitor/cangccm001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetMonitorInfo/cangetmonitorinfo001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetMonitorInfo/cangetmonitorinfo001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetOwnedMonitorInfo/cangetinfo001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetOwnedMonitorInfo/cangetinfo001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetSourceDebugExtension/cangetsde001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetSourceDebugExtension/cangetsde001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetSyntheticAttribute/cangetattr001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetSyntheticAttribute/cangetattr001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canPopFrames/canpopframes001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canPopFrames/canpopframes001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canRedefineClasses/canredefineclasses001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canRedefineClasses/canredefineclasses001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canRequestVMDeathEvent/canreqvmdev001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canRequestVMDeathEvent/canreqvmdev001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canUnrestrictedlyRedefineClasses/curc001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canUnrestrictedlyRedefineClasses/curc001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canUseInstanceFilters/canusefilters001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canUseInstanceFilters/canusefilters001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canWatchFieldAccess/canwatchaccess001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canWatchFieldAccess/canwatchaccess001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canWatchFieldModification/canwatchmod001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canWatchFieldModification/canwatchmod001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/classesByName/classesbyname001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/classesByName/classesbyname001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/description/description001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/description/description001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/eventQueue/eventqueue001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/eventQueue/eventqueue001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/eventRequestManager/eventrmanager001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/eventRequestManager/eventrmanager001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/exit/exit001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/exit/exit001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/exit/exit002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/exit/exit002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/getDefaultStratum/getdefaultstratum001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/getDefaultStratum/getdefaultstratum001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/instanceCounts/instancecounts001/instancecounts001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/instanceCounts/instancecounts003/instancecounts003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/instanceCounts/instancecounts004/instancecounts004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/mirrorOf_bool/mirrorof_bool001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/mirrorOf_bool/mirrorof_bool001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/mirrorOf_byte/mirrorof_byte001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/mirrorOf_byte/mirrorof_byte001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/mirrorOf_char/mirrorof_char001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/mirrorOf_char/mirrorof_char001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/mirrorOf_double/mirrorof_double001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/mirrorOf_double/mirrorof_double001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/mirrorOf_float/mirrorof_float001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/mirrorOf_float/mirrorof_float001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/mirrorOf_int/mirrorof_int001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/mirrorOf_int/mirrorof_int001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/mirrorOf_long/mirrorof_long001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/mirrorOf_long/mirrorof_long001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/mirrorOf_short/mirrorof_short001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/mirrorOf_short/mirrorof_short001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/mirrorOf_string/mirrorof_string001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/mirrorOf_string/mirrorof_string001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/name/name001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/name/name001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/process/process001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/process/process001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses009.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses009/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses010.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses010/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses011.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses011/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses012.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses012/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses013.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses013/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses014.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses014/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses015.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses015/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses016.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses016/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses020.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses020/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses022.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses022/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses024.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses024/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses025.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses025/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses026.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses026/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses027.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses027/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses028.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses028/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses029.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses029/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses030.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses030/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses031.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses031/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses032.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses032/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses034.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses034/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses035.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses035/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/resume/resume001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/resume/resume001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/setDefaultStratum/setDefaultStratum002/setDefaultStratum002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/setDefaultStratum/setDefaultStratum003/setDefaultStratum003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/setDefaultStratum/setdefaultstratum001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/setDefaultStratum/setdefaultstratum001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/suspend/suspend001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/suspend/suspend001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/topLevelThreadGroups/toplevelgroups001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/topLevelThreadGroups/toplevelgroups001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/version/version001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/version/version001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/allConnectors/allconnectors001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/allConnectors/allconnectors001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/attachingConnectors/attaching001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/attachingConnectors/attaching001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/connectedVirtualMachines/convm001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/connectedVirtualMachines/convm001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/connectedVirtualMachines/convm002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/connectedVirtualMachines/convm002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/connectedVirtualMachines/convm003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/connectedVirtualMachines/convm003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/createVirtualMachine/createVM001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/createVirtualMachine/createVM001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/createVirtualMachine/createVM002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/createVirtualMachine/createVM002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/createVirtualMachine/createVM003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/createVirtualMachine/createVM004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/createVirtualMachine/createVM005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/defaultConnector/default001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/defaultConnector/default001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/launchingConnectors/launching001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/launchingConnectors/launching001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/listeningConnectors/listening001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/listeningConnectors/listening001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/majorInterfaceVersion/major001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/majorInterfaceVersion/major001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/minorInterfaceVersion/minor001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/minorInterfaceVersion/minor001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VoidType/_itself_/voidtype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VoidType/_itself_/voidtype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VoidType/toString/tostring001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VoidType/toString/tostring001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VoidValue/equals/equals001/equals001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VoidValue/equals/equals002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VoidValue/equals/equals002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VoidValue/hashCode/hashcode001/hashcode001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VoidValue/toString/tostring001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VoidValue/toString/tostring001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointEvent/_itself_/wevent001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointEvent/_itself_/wevent001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointEvent/field/field001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointEvent/field/field001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointEvent/object/object001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointEvent/object/object001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointEvent/valueCurrent/valuecur001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointEvent/valueCurrent/valuecur001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/_bounds_/filters001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/_bounds_/filters001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassExclusionFilter/filter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassExclusionFilter/filter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassExclusionFilter/filter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassExclusionFilter/filter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassExclusionFilter/filter003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassExclusionFilter/filter003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassExclusionFilter/filter004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassExclusionFilter/filter004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_s/filter_s001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_s/filter_s001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_s/filter_s002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_s/filter_s002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_s/filter_s003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_s/filter_s003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_s/filter_s004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_s/filter_s004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter007/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter008.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter008/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter007/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter008.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter008/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/field/field001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/field/field001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/field/field002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/field/field002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/stress/ClassPrepareEvents/ClassPrepareEvents001/ClassPrepareEvents001.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Binder.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/ClassExclusionFilterTest.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/ClassFilterTest_ClassName.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/ClassFilterTest_ReferenceType.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/InstanceFilterTest.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/OwnedMonitorsDebugger.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/SerialExecutionDebugger.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/StressTestTemplate.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/TestDebuggerType1.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/ThreadFilterTest.java Changeset: f7f291c5 Author: Phil Race Date: 2024-03-21 22:48:06 +0000 URL: https://git.openjdk.org/leyden/commit/f7f291c5d4d2d01dab3ccda7518ebc13f6bd58f6 8328301: Convert Applet test ManualHTMLDataFlavorTest.java to main program Reviewed-by: honkar - test/jdk/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.html ! test/jdk/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.java Changeset: 46809b39 Author: Archie Cobbs Committer: Vicente Romero Date: 2024-03-21 22:54:15 +0000 URL: https://git.openjdk.org/leyden/commit/46809b396ca76210f7939c8edf5a8263c29d3ddb 8324736: Invalid end positions for EMPTY_STATEMENT Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/langtools/tools/javac/parser/ReversedSourcePositions.java Changeset: 0efd9dc0 Author: Harshitha Onkar Date: 2024-03-21 23:06:33 +0000 URL: https://git.openjdk.org/leyden/commit/0efd9dc09b969846f79fb8ca16ddf565117d52b6 8328398: Convert java/awt/im/4490692/bug4490692.html applet test to main Reviewed-by: achung, azvegint - test/jdk/java/awt/im/4490692/bug4490692.html - test/jdk/java/awt/im/4490692/bug4490692.java + test/jdk/java/awt/im/bug4490692.java Changeset: 4d36c4ad Author: Serguei Spitsyn Date: 2024-03-22 00:30:07 +0000 URL: https://git.openjdk.org/leyden/commit/4d36c4adcc47630ddc7149c48c06dc8a93c1be5c 8328285: GetOwnedMonitorInfo functions should use JvmtiHandshake Reviewed-by: pchilanomate, lmesnik ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiEnvBase.hpp ! src/hotspot/share/runtime/escapeBarrier.cpp Changeset: da009214 Author: Koichi Sakata Date: 2024-03-22 00:56:33 +0000 URL: https://git.openjdk.org/leyden/commit/da009214f19f73965495b8462c9dcff5db8ae7ae 8320404: Double whitespace in SubTypeCheckNode::dump_spec output Reviewed-by: chagedorn, thartmann ! src/hotspot/share/opto/subtypenode.cpp Changeset: 177b8a24 Author: Tejesh R Date: 2024-03-22 03:21:35 +0000 URL: https://git.openjdk.org/leyden/commit/177b8a241c11782b302607c0068b15b38112e67c 8327840: Automate javax/swing/border/Test4129681.java Reviewed-by: abhiscxk, prr ! test/jdk/javax/swing/border/Test4129681.java Changeset: 256d48b1 Author: Abhishek Kumar Date: 2024-03-22 03:40:33 +0000 URL: https://git.openjdk.org/leyden/commit/256d48b19694e86bb26d67ed56de8ac94a31f4ff 8327980: Convert javax/swing/JToggleButton/4128979/bug4128979.java applet test to main Reviewed-by: honkar, tr - test/jdk/javax/swing/JToggleButton/4128979/bug4128979.html - test/jdk/javax/swing/JToggleButton/4128979/bug4128979.java + test/jdk/javax/swing/JToggleButton/bug4128979.java Changeset: 9bc741d0 Author: Christian Stein Date: 2024-03-22 05:29:20 +0000 URL: https://git.openjdk.org/leyden/commit/9bc741d04f0c2e731f67ac21144812a55d0ea03d 8328339: Static import prevents source launcher from finding class with main method Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/ProgramDescriptor.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java ! test/langtools/tools/javac/launcher/SourceLauncherTest.java Changeset: d44aaa37 Author: Prasadrao Koppula Committer: Sean Coffey Date: 2024-03-22 07:02:37 +0000 URL: https://git.openjdk.org/leyden/commit/d44aaa37f98dd383aebbec097427feb1f1c29b74 8326643: JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message Reviewed-by: djelinski, coffeys, jjiang, ascarpino ! src/java.base/share/classes/sun/security/ssl/ServerHello.java + test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java Changeset: 940d1965 Author: Matthias Baesken Date: 2024-03-22 07:09:37 +0000 URL: https://git.openjdk.org/leyden/commit/940d1965f831a9f7e4f1ce34e381c038827c7ca2 8328604: remove on_aix() function Reviewed-by: clanger, stuefe ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/aix/os_aix.hpp Changeset: e669d14d Author: Guoxiong Li Date: 2024-03-22 08:43:45 +0000 URL: https://git.openjdk.org/leyden/commit/e669d14d4789f0047e8ef2112798f92ed28b31ca 8328671: Mark `allocate_new_tlab` and `unsafe_max_tlab_alloc` of `CollectedHeap` as `pure virtual` Reviewed-by: stefank, tschatzl ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/collectedHeap.hpp Changeset: b334a8e5 Author: Joachim Kern Committer: Martin Doerr Date: 2024-03-22 09:27:09 +0000 URL: https://git.openjdk.org/leyden/commit/b334a8e5fc2c05e9e64402ca8185f3ab5140b3a7 8328272: [AIX] Use flag kind "diagnostic" for platform specific flags Reviewed-by: mdoerr, stuefe ! src/hotspot/os/aix/globals_aix.hpp Changeset: 38e3cda4 Author: Abhishek Kumar Date: 2024-03-22 09:46:08 +0000 URL: https://git.openjdk.org/leyden/commit/38e3cda4420ef921cc6e43cb18338ec18c12011f 8328670: Automate and open source few closed manual applet test Reviewed-by: psadhukhan, tr + test/jdk/javax/swing/JInternalFrame/Ctrli.java + test/jdk/javax/swing/JMenuItem/JActionCommandTest.java Changeset: cd534f81 Author: Prasanta Sadhukhan Date: 2024-03-22 10:25:13 +0000 URL: https://git.openjdk.org/leyden/commit/cd534f8197341fbe3b3811f5be43c88090e16366 8328673: Convert closed text/html/CSS manual applet test to main Reviewed-by: abhiscxk, aivanov + test/jdk/javax/swing/text/html/CSS/bug4271058.java + test/jdk/javax/swing/text/html/CSS/bug4286458.java Changeset: d379afbc Author: Doug Simon Date: 2024-03-22 10:57:20 +0000 URL: https://git.openjdk.org/leyden/commit/d379afbc11b82d72506ee71a2b36b04cf20f48ae 8328312: runtime/stack/Stack0*.java fails intermittently on libgraal Reviewed-by: lmesnik, dholmes ! test/hotspot/jtreg/runtime/stack/Stack011.java ! test/hotspot/jtreg/runtime/stack/Stack012.java Changeset: 528efe20 Author: Abhishek Kumar Date: 2024-03-22 11:10:33 +0000 URL: https://git.openjdk.org/leyden/commit/528efe206d5ee3775b01f3b90600ca3cab6c96f0 8328484: Convert and Opensource few JFileChooser applet test to main Reviewed-by: psadhukhan, tr + test/jdk/javax/swing/JFileChooser/EnterEmptyDirectory.java + test/jdk/javax/swing/JFileChooser/FileSelectionTests.java + test/jdk/javax/swing/JFileChooser/ShowHiddenFiles.java Changeset: e06b568c Author: Albert Mingkun Yang Date: 2024-03-22 12:08:56 +0000 URL: https://git.openjdk.org/leyden/commit/e06b568c3c645dc9bb3d3e601e5429bb6a9b31f1 8328602: Parallel: Incorrect assertion in fill_dense_prefix_end Reviewed-by: gli, iwalulya ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 638708ca Author: Alexander Zvegintsev Date: 2024-03-22 13:13:13 +0000 URL: https://git.openjdk.org/leyden/commit/638708cad8228f62caf633015973403164675560 8328697: SubMenuShowTest and SwallowKeyEvents tests stabilization Reviewed-by: kizune ! test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.java ! test/jdk/java/awt/event/KeyEvent/SwallowKeyEvents/SwallowKeyEvents.java Changeset: e80619a0 Author: Magnus Ihse Bursie Date: 2024-03-22 14:12:26 +0000 URL: https://git.openjdk.org/leyden/commit/e80619a032c16d16de6e063e7650b60bc317ee7e 8328680: Introduce JDK_LIB, and clean up module native compilation Reviewed-by: erikj, jwaters ! make/autoconf/libraries.m4 ! make/autoconf/spec.gmk.template ! make/common/JdkNativeCompilation.gmk ! make/common/modules/LauncherCommon.gmk ! make/hotspot/lib/CompileGtest.gmk ! make/modules/java.instrument/Lib.gmk ! make/modules/java.management/Lib.gmk ! make/modules/java.prefs/Lib.gmk ! make/modules/java.rmi/Launcher.gmk ! make/modules/java.rmi/Lib.gmk ! make/modules/java.scripting/Launcher.gmk ! make/modules/java.security.jgss/Launcher.gmk ! make/modules/java.security.jgss/Lib.gmk ! make/modules/java.smartcardio/Lib.gmk ! make/modules/jdk.attach/Lib.gmk ! make/modules/jdk.compiler/Launcher.gmk ! make/modules/jdk.crypto.cryptoki/Lib.gmk ! make/modules/jdk.crypto.mscapi/Lib.gmk ! make/modules/jdk.hotspot.agent/Launcher.gmk ! make/modules/jdk.hotspot.agent/Lib.gmk ! make/modules/jdk.httpserver/Launcher.gmk ! make/modules/jdk.incubator.vector/Lib.gmk ! make/modules/jdk.internal.le/Lib.gmk ! make/modules/jdk.jartool/Launcher.gmk ! make/modules/jdk.javadoc/Launcher.gmk ! make/modules/jdk.jcmd/Launcher.gmk ! make/modules/jdk.jconsole/Launcher.gmk ! make/modules/jdk.jdeps/Launcher.gmk ! make/modules/jdk.jdi/Launcher.gmk ! make/modules/jdk.jdi/Lib.gmk ! make/modules/jdk.jdwp.agent/Lib.gmk ! make/modules/jdk.jfr/Launcher.gmk ! make/modules/jdk.jlink/Launcher.gmk ! make/modules/jdk.jpackage/Launcher.gmk ! make/modules/jdk.jshell/Launcher.gmk ! make/modules/jdk.jstatd/Launcher.gmk ! make/modules/jdk.management.agent/Lib.gmk ! make/modules/jdk.management/Lib.gmk ! make/modules/jdk.net/Lib.gmk ! make/modules/jdk.sctp/Lib.gmk ! make/modules/jdk.security.auth/Lib.gmk Changeset: f207aa94 Author: Aleksey Shipilev Date: 2024-03-22 14:12:37 +0000 URL: https://git.openjdk.org/leyden/commit/f207aa94f9296932276c2952252b263efc793b3f 8326960: GHA: RISC-V sysroot cannot be debootstrapped due to ongoing Debian t64 transition Reviewed-by: fyang, erikj ! .github/workflows/build-cross-compile.yml Changeset: 709410d8 Author: Maurizio Cimadamore Date: 2024-03-22 15:09:27 +0000 URL: https://git.openjdk.org/leyden/commit/709410d8a4ca176c52d9c0abf80ed59eeb6bdaf3 8328679: Improve comment for UNSAFE_ENTRY_SCOPED in unsafe.cpp Reviewed-by: jvernee, dholmes ! src/hotspot/share/prims/unsafe.cpp Changeset: 13cf0707 Author: Martin Balao Date: 2024-03-22 15:28:05 +0000 URL: https://git.openjdk.org/leyden/commit/13cf0707f903609c9bda99a9bf7511f494f9feae 8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software Token Reviewed-by: djelinski ! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_keymgmt.c + test/jdk/sun/security/pkcs11/Mac/TestLargeSecretKeys.java Changeset: 739957ca Author: Alexander Zuev Date: 2024-03-22 15:40:38 +0000 URL: https://git.openjdk.org/leyden/commit/739957ca1e3b9ac9131a68990178e92691744157 8328384: Convert java/awt/FileDialog/FileDialogOpenDirTest test to main Reviewed-by: azvegint + test/jdk/java/awt/FileDialog/FileDialogOpenDirTest.java - test/jdk/java/awt/FileDialog/FileDialogOpenDirTest/FileDialogOpenDirTest.html - test/jdk/java/awt/FileDialog/FileDialogOpenDirTest/FileDialogOpenDirTest.java Changeset: b7a51dd0 Author: Alexander Zuev Date: 2024-03-22 15:52:52 +0000 URL: https://git.openjdk.org/leyden/commit/b7a51dd0e8d56a9673b2c802d69019c23d43cb76 8328382: Convert java/awt/FileDialog/FileDialogForPackages test to main Reviewed-by: psadhukhan, azvegint + test/jdk/java/awt/FileDialog/FileDialogForPackages.java - test/jdk/java/awt/FileDialog/FileDialogForPackages/FileDialogForPackages.html - test/jdk/java/awt/FileDialog/FileDialogForPackages/FileDialogForPackages.java Changeset: ce7ebaa6 Author: Jesper Wilhelmsson Date: 2024-03-22 16:00:52 +0000 URL: https://git.openjdk.org/leyden/commit/ce7ebaa606f96fdfee66d300b56022d9903b5ae3 8328812: Update and move siphash license Reviewed-by: lfoltan = src/java.base/share/legal/siphash.md Changeset: 4d932d61 Author: Nizar Benalla Committer: Justin Lu Date: 2024-03-22 16:11:30 +0000 URL: https://git.openjdk.org/leyden/commit/4d932d615c78f45516a4f136398e7610546065a6 8326853: Missing `@since` tags for Charset related methods added in Java 10 Reviewed-by: jlu, naoto ! src/java.base/share/classes/java/nio/channels/Channels.java ! src/java.base/share/classes/java/util/Formatter.java Changeset: 23ebd9c3 Author: Phil Race Date: 2024-03-22 17:17:06 +0000 URL: https://git.openjdk.org/leyden/commit/23ebd9c3c69d09e6afe672d00b43da2ccc493480 8328555: hidpi problems for test java/awt/Dialog/DialogAnotherThread/JaWSTest.java Reviewed-by: aivanov + test/jdk/java/awt/Dialog/JaWSTest.java Changeset: c7bbf849 Author: Harshitha Onkar Date: 2024-03-22 17:31:10 +0000 URL: https://git.openjdk.org/leyden/commit/c7bbf849290b39b8e89290234d70d8333df24710 8328190: Convert AWTPanelSmoothWheel.html applet test to main Reviewed-by: azvegint, abhiscxk, aivanov + test/jdk/java/awt/event/MouseEvent/AWTPanelSmoothWheel.java - test/jdk/java/awt/event/MouseEvent/AWTPanelSmoothWheel/AWTPanelSmoothWheel.html - test/jdk/java/awt/event/MouseEvent/AWTPanelSmoothWheel/AWTPanelSmoothWheel.java Changeset: 4324e3be Author: Zhengyu Gu Date: 2024-03-22 19:21:13 +0000 URL: https://git.openjdk.org/leyden/commit/4324e3be9ea8233b3625440330b9e8a269672f85 8328612: AdaptiveSizePolicySpaceOverheadTester::is_exceeded() print max_eden_size twice Reviewed-by: ayang ! src/hotspot/share/gc/shared/adaptiveSizePolicy.cpp Changeset: f33a8445 Author: Calvin Cheung Date: 2024-03-22 20:15:13 +0000 URL: https://git.openjdk.org/leyden/commit/f33a8445ebfc3089e91688383db26b91e582658c 8325536: JVM crash during CDS archive creation with -XX:+AllowArchivingWithJavaAgent Reviewed-by: iklam, matsaave ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/classfile/klassFactory.cpp + test/hotspot/jtreg/runtime/cds/appcds/jvmti/dumpingWithAgent/AppWithBMH.java ! test/hotspot/jtreg/runtime/cds/appcds/jvmti/dumpingWithAgent/DumpingWithJavaAgent.java ! test/hotspot/jtreg/runtime/cds/appcds/jvmti/dumpingWithAgent/SimpleAgent.java Changeset: c013fa18 Author: Sergey Bylokhov Date: 2024-03-22 21:03:57 +0000 URL: https://git.openjdk.org/leyden/commit/c013fa18119bbd2e355d5c0d13cd8c172892800a 8328194: Add a test to check default rendering engine Reviewed-by: prr, tr + test/jdk/sun/java2d/marlin/DefaultRenderingEngine.java Changeset: 476421ef Author: Damon Nguyen Date: 2024-03-22 23:09:12 +0000 URL: https://git.openjdk.org/leyden/commit/476421efe574eca6ba92aaa7fc86dfca99fdd7b2 8328370: Convert java/awt/print/Dialog/PrintApplet.java applet test to main Reviewed-by: honkar, psadhukhan - test/jdk/java/awt/print/Dialog/PrintApplet.html - test/jdk/java/awt/print/Dialog/PrintApplet.java + test/jdk/java/awt/print/Dialog/PrintModalDialog.java Changeset: bc739639 Author: Alex Menkov Date: 2024-03-22 23:30:54 +0000 URL: https://git.openjdk.org/leyden/commit/bc73963974a824d77d54b8b0edbf8f05262b721c 8328303: 3 JDI tests timed out with UT enabled Reviewed-by: cjplummer, sspitsyn, dcubed ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/referenceType/refType001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/thread/thread001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/threadDeathRequests/thrdeathreq001.java Changeset: c7b9dc46 Author: Gui Cao Committer: Fei Yang Date: 2024-03-25 01:18:50 +0000 URL: https://git.openjdk.org/leyden/commit/c7b9dc463a7e0347fc2e2ce5578e8fb39ea0b733 8328404: RISC-V: Fix potential crash in C2_MacroAssembler::arrays_equals Reviewed-by: fyang ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/riscv.ad Changeset: 9f920b9b Author: Jasmine Karthikeyan Committer: Emanuel Peter Date: 2024-03-25 06:23:11 +0000 URL: https://git.openjdk.org/leyden/commit/9f920b9bbf8a64e2c2db085cf3da30db37c0d1bc 8324655: Identify integer minimum and maximum patterns created with if statements Reviewed-by: epeter, qamai ! src/hotspot/share/opto/addnode.cpp ! src/hotspot/share/opto/addnode.hpp ! src/hotspot/share/opto/movenode.cpp ! src/hotspot/share/opto/movenode.hpp + test/hotspot/jtreg/compiler/c2/irTests/TestIfMinMax.java ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java + test/micro/org/openjdk/bench/vm/compiler/IfMinMax.java Changeset: acc4a828 Author: Kim Barrett Date: 2024-03-25 07:07:47 +0000 URL: https://git.openjdk.org/leyden/commit/acc4a828184bd2838a5c0b572f404aa1edaf59e2 8328862: Remove unused GrowableArrayFilterIterator Reviewed-by: dholmes ! src/hotspot/share/utilities/growableArray.hpp Changeset: cf9b5a71 Author: Matthias Baesken Date: 2024-03-25 08:33:31 +0000 URL: https://git.openjdk.org/leyden/commit/cf9b5a71bd66a51147d0dbf9ecf4038101a1e191 8328776: [AIX] remove checked_vmgetinfo, use vmgetinfo directly Reviewed-by: clanger, lucy ! src/hotspot/os/aix/os_aix.cpp Changeset: 19a0151a Author: Raffaello Giulietti Date: 2024-03-25 08:47:14 +0000 URL: https://git.openjdk.org/leyden/commit/19a0151a529ca69b3bef1ca821d9292018efbb7c 8328700: Unused import and variable should be deleted in regex package Reviewed-by: redestad, rriggs, bpb, naoto, iris ! src/java.base/share/classes/java/util/regex/CharPredicates.java ! src/java.base/share/classes/java/util/regex/Pattern.java Changeset: b235682a Author: Matthias Baesken Date: 2024-03-25 09:21:04 +0000 URL: https://git.openjdk.org/leyden/commit/b235682a18653ab16f2d9b03b1e55698a91273b7 8328709: AIX os::get_summary_cpu_info support Power 10 Reviewed-by: lucy, jkern ! src/hotspot/os/aix/os_aix.cpp Changeset: 93579c29 Author: Per Minborg Date: 2024-03-25 09:37:24 +0000 URL: https://git.openjdk.org/leyden/commit/93579c29e3ba60a8bc16d712e7ffc733f324a223 8323552: AbstractMemorySegmentImpl#mismatch returns -1 when comparing distinct areas of the same instance of MemorySegment Reviewed-by: mcimadamore ! src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java ! test/jdk/java/foreign/TestMismatch.java Changeset: f67ec19e Author: Prasanta Sadhukhan Date: 2024-03-25 10:11:43 +0000 URL: https://git.openjdk.org/leyden/commit/f67ec19e236e3b4d2d4d4993a7d64b8de052d241 8079786: [macosx] Test java/awt/Frame/DisposeParentGC/DisposeParentGC.java fails for Mac only Reviewed-by: prr ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Frame/DisposeParentGC/DisposeParentGC.java Changeset: 29ba4b7d Author: Aleksey Shipilev Date: 2024-03-25 11:45:51 +0000 URL: https://git.openjdk.org/leyden/commit/29ba4b7d1e62a834c1693fe6ad383c19467afc81 8328705: GHA: Cross-compilation jobs do not require build JDK Reviewed-by: erikj, ihse ! .github/workflows/build-cross-compile.yml ! .github/workflows/main.yml Changeset: 0c1b254b Author: Daniel Lund?n Committer: Tobias Hartmann Date: 2024-03-25 12:04:44 +0000 URL: https://git.openjdk.org/leyden/commit/0c1b254be9ddd3883313f80b61229eacf09aa862 8326438: C2: assert(ld->in(1)->Opcode() == Op_LoadN) failed: Assumption invalid: input to DecodeN is not LoadN Reviewed-by: kvn, rcastanedalo, thartmann ! src/hotspot/share/opto/graphKit.cpp Changeset: cb2a6713 Author: Roland Westrelin Date: 2024-03-25 12:55:08 +0000 URL: https://git.openjdk.org/leyden/commit/cb2a6713596548d76c03912709656172b0bbcc76 8324121: SIGFPE in PhaseIdealLoop::extract_long_range_checks Reviewed-by: kvn, chagedorn ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp + test/hotspot/jtreg/compiler/rangechecks/TestLargeScaleInLongRCOverflow.java Changeset: 142c311e Author: Zhengyu Gu Date: 2024-03-25 13:04:07 +0000 URL: https://git.openjdk.org/leyden/commit/142c311e3b9bd3f00edaa6ba7bcbc9fc285ee9b9 8328744: Parallel: Parallel GC throws OOM before heap is fully expanded Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/parallel/psScavenge.cpp Changeset: af15c68f Author: Roland Westrelin Date: 2024-03-25 13:45:16 +0000 URL: https://git.openjdk.org/leyden/commit/af15c68f3ccb72537b0a60d942f12d600f13ebb6 8321278: C2: Partial peeling fails with assert "last_peel <- first_not_peeled" Reviewed-by: chagedorn, thartmann ! src/hotspot/share/opto/domgraph.cpp + test/hotspot/jtreg/compiler/loopopts/TestPartialPeelingAtSingleInputRegion.java Changeset: 26b2ec48 Author: Magnus Ihse Bursie Date: 2024-03-25 15:04:38 +0000 URL: https://git.openjdk.org/leyden/commit/26b2ec4847df4b41cbb7a7dd86d78bd3451e3e51 8328824: Clean up java.base native compilation Reviewed-by: erikj ! make/Main.gmk ! make/common/JdkNativeCompilation.gmk ! make/hotspot/lib/CompileGtest.gmk ! make/modules/java.base/Copy.gmk ! make/modules/java.base/Launcher.gmk ! make/modules/java.base/Lib.gmk ! make/modules/java.base/lib/CoreLibraries.gmk Changeset: a1fbbffb Author: Damon Nguyen Date: 2024-03-25 16:00:14 +0000 URL: https://git.openjdk.org/leyden/commit/a1fbbffb5e0d7e41a9c3041b7e64382780e86f50 8328717: Convert javax/swing/JColorChooser/8065098/bug8065098.java applet test to main Reviewed-by: honkar, tr ! test/jdk/javax/swing/JColorChooser/8065098/JColorChooserDnDTest.java - test/jdk/javax/swing/JColorChooser/8065098/bug8065098.html ! test/jdk/javax/swing/JColorChooser/8065098/bug8065098.java Changeset: 70a15c73 Author: Rajan Halade Date: 2024-03-25 16:31:42 +0000 URL: https://git.openjdk.org/leyden/commit/70a15c73638f45b9ed629abc0ea2d86a324bf624 8328825: Google CAInterop test failures Reviewed-by: shade ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java Changeset: 907e30ff Author: Christoph Langer Date: 2024-03-25 16:31:52 +0000 URL: https://git.openjdk.org/leyden/commit/907e30ff00abd6cd4935987810d282f46ec07704 8325579: Inconsistent behavior in com.sun.jndi.ldap.Connection::createSocket Reviewed-by: dfuchs, aefimov ! src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java ! src/java.naming/share/classes/module-info.java ! test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java Changeset: 78d1b904 Author: Alisen Chung Date: 2024-03-25 17:02:48 +0000 URL: https://git.openjdk.org/leyden/commit/78d1b9046830198cd61c505f04f245a430878a5b 8328380: Remove applet usage from JColorChooser tests Test6348456 Reviewed-by: honkar - test/jdk/javax/swing/JColorChooser/Test6348456.html ! test/jdk/javax/swing/JColorChooser/Test6348456.java Changeset: c7cf6020 Author: Alexander Zuev Date: 2024-03-25 17:17:33 +0000 URL: https://git.openjdk.org/leyden/commit/c7cf6020782525eb17ff3013195a81d711a4fce1 8328385: Convert java/awt/FileDialog/FileDialogReturnTest test to main Reviewed-by: achung, prr + test/jdk/java/awt/FileDialog/FileDialogReturnTest.java - test/jdk/java/awt/FileDialog/FileDialogReturnTest/FileDialogReturnTest.html - test/jdk/java/awt/FileDialog/FileDialogReturnTest/FileDialogReturnTest.java Changeset: 447436e1 Author: Aleksey Shipilev Date: 2024-03-25 18:15:45 +0000 URL: https://git.openjdk.org/leyden/commit/447436e18c754424a62af5135fb3a8973564091d 8328948: GHA: Restoring sysroot from cache skips the build after JDK-8326960 Reviewed-by: clanger, ihse ! .github/workflows/build-cross-compile.yml Changeset: fb8f2a0a Author: Alexander Zvegintsev Date: 2024-03-25 18:59:28 +0000 URL: https://git.openjdk.org/leyden/commit/fb8f2a0a929ebe7f65c69741712b89bbb403ade9 8328562: Convert java/awt/InputMethods/DiacriticsTest/DiacriticsTest.java applet test to main Reviewed-by: tr, prr - test/jdk/java/awt/InputMethods/DiacriticsTest/DiacriticsTest.html ! test/jdk/java/awt/InputMethods/DiacriticsTest/DiacriticsTest.java Changeset: 27ac39a2 Author: Damon Nguyen Date: 2024-03-25 21:24:44 +0000 URL: https://git.openjdk.org/leyden/commit/27ac39a2bc8250bfae859568cb0ee0963900aafa 8328719: Convert java/awt/print/PageFormat/SetOrient.html applet test to main Reviewed-by: psadhukhan, prr - test/jdk/java/awt/print/PageFormat/SetOrient.html ! test/jdk/java/awt/print/PageFormat/SetOrient.java Changeset: 4047a362 Author: Damon Nguyen Date: 2024-03-25 23:51:31 +0000 URL: https://git.openjdk.org/leyden/commit/4047a3623a44d86df2b82565f33ce739a882802d 8328730: Convert java/awt/print/bug8023392/bug8023392.html applet test to main Reviewed-by: prr, honkar + test/jdk/java/awt/print/bug8023392.java - test/jdk/java/awt/print/bug8023392/bug8023392.html - test/jdk/java/awt/print/bug8023392/bug8023392.java Changeset: 7560dbb9 Author: Alexander Zuev Date: 2024-03-26 01:02:20 +0000 URL: https://git.openjdk.org/leyden/commit/7560dbb9258f651a221bc8350816845735929fd9 8316324: Opensource five miscellaneous Swing tests Reviewed-by: prr + test/jdk/javax/swing/InputVerifier/bug4774166.java + test/jdk/javax/swing/JButton/DefaultButtonLeak.java + test/jdk/javax/swing/JButton/bug4385611.java + test/jdk/javax/swing/JComponent/bug4706883.java + test/jdk/javax/swing/plaf/motif/bug4150591.java Changeset: 5f7432f7 Author: Serguei Spitsyn Date: 2024-03-26 02:21:47 +0000 URL: https://git.openjdk.org/leyden/commit/5f7432f7b1ca52941b717fd35a929c91fbdd276d 8328758: GetCurrentContendedMonitor function should use JvmtiHandshake Reviewed-by: lmesnik, pchilanomate ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiEnvBase.hpp Changeset: 5d19d155 Author: Koichi Sakata Date: 2024-03-26 04:17:42 +0000 URL: https://git.openjdk.org/leyden/commit/5d19d15517f08e13dc4b2025bf289091e47fa55b 8325186: JVMTI VirtualThreadGetThreadStateClosure class is no longer used and should be removed Reviewed-by: lmesnik, sspitsyn ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiEnvBase.hpp Changeset: 44549b60 Author: Jie Fu Date: 2024-03-26 06:01:06 +0000 URL: https://git.openjdk.org/leyden/commit/44549b605a7aad1e3143a4058ef6504a7c04167a 8329012: IGV: Update required JDK version in README.md Reviewed-by: rcastanedalo ! src/utils/IdealGraphVisualizer/README.md Changeset: 9d441e3e Author: Leo Korinth Date: 2024-03-26 09:06:39 +0000 URL: https://git.openjdk.org/leyden/commit/9d441e3e56e733d64dbadde6854761e4545c1c70 8283223: gc/stringdedup/TestStringDeduplicationFullGC.java#Parallel failed with "RuntimeException: String verification failed" Reviewed-by: tschatzl, kbarrett ! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java Changeset: 7b1f2c80 Author: Magnus Ihse Bursie Date: 2024-03-26 09:35:32 +0000 URL: https://git.openjdk.org/leyden/commit/7b1f2c801fee6366ee37e873cda29c1ae7ad7e74 8327493: Update minimum Xcode version in docs Reviewed-by: clanger ! doc/building.html ! doc/building.md Changeset: b9c76ded Author: Matthias Baesken Date: 2024-03-26 10:00:56 +0000 URL: https://git.openjdk.org/leyden/commit/b9c76dedf4aa2248a5e561a535c9e3e181f7836a 8329074: AIX build fails after JDK-8328824 Reviewed-by: clanger, goetz ! make/modules/java.base/lib/CoreLibraries.gmk Changeset: cc1800fa Author: Elif Aslan Committer: Aleksey Shipilev Date: 2024-03-26 11:47:53 +0000 URL: https://git.openjdk.org/leyden/commit/cc1800fa4de3c1369efd46f5ca967ea82763f5d5 8327998: Enable java/lang/ProcessBuilder/JspawnhelperProtocol.java on Mac Reviewed-by: gli, shade, rriggs ! test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java Changeset: 472fcb6e Author: Guoxiong Li Date: 2024-03-26 13:11:28 +0000 URL: https://git.openjdk.org/leyden/commit/472fcb6e6e5fce4d5166a73894d1e7e4bd91bc58 8328508: Unify the signatures of the methods address_for_index() and index_for() in BOT implementations Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/serial/serialBlockOffsetTable.cpp ! src/hotspot/share/gc/serial/serialBlockOffsetTable.hpp ! src/hotspot/share/gc/serial/serialBlockOffsetTable.inline.hpp ! src/hotspot/share/gc/serial/vmStructs_serial.hpp ! src/hotspot/share/gc/shared/cardTable.cpp ! src/hotspot/share/gc/shared/cardTable.hpp Changeset: da8a095a Author: Guoxiong Li Date: 2024-03-26 14:34:52 +0000 URL: https://git.openjdk.org/leyden/commit/da8a095a19c90e7ee2b45fab9b533a1092887023 8328928: Serial: Use IsGCActiveMark instead of AutoModifyRestore in SerialHeap::do_collection Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/serial/serialHeap.cpp Changeset: 153410f4 Author: Matthias Baesken Date: 2024-03-26 16:24:05 +0000 URL: https://git.openjdk.org/leyden/commit/153410f480c372604e5825bfcd3a63f137e6a013 8328930: [AIX] remove pase related coding Reviewed-by: clanger, lucy ! src/hotspot/os/aix/attachListener_aix.cpp - src/hotspot/os/aix/libo4.cpp - src/hotspot/os/aix/libo4.hpp ! src/hotspot/os/aix/libodm_aix.hpp ! src/hotspot/os/aix/libperfstat_aix.hpp ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/aix/os_aix.hpp ! src/jdk.attach/aix/native/libattach/VirtualMachineImpl.c Changeset: 89e0889a Author: Doug Simon Date: 2024-03-26 17:36:18 +0000 URL: https://git.openjdk.org/leyden/commit/89e0889ab3beb96103ee381d9a54614e49e6d9d7 8328858: More runtime/stack tests fail intermittently on libgraal Reviewed-by: dholmes, never ! test/hotspot/jtreg/runtime/stack/Stack003.java ! test/hotspot/jtreg/runtime/stack/Stack004.java ! test/hotspot/jtreg/runtime/stack/Stack005.java ! test/hotspot/jtreg/runtime/stack/Stack006.java ! test/hotspot/jtreg/runtime/stack/Stack007.java ! test/hotspot/jtreg/runtime/stack/Stack008.java ! test/hotspot/jtreg/runtime/stack/Stack009.java ! test/hotspot/jtreg/runtime/stack/Stack010.java ! test/hotspot/jtreg/runtime/stack/Stack013.java ! test/hotspot/jtreg/runtime/stack/Stack014.java ! test/hotspot/jtreg/runtime/stack/Stack015.java ! test/hotspot/jtreg/runtime/stack/Stack016.java Changeset: db01fcd6 Author: Damon Nguyen Date: 2024-03-26 19:00:44 +0000 URL: https://git.openjdk.org/leyden/commit/db01fcd6d8c24b01a1f23c71b2917ff396b0686f 8328827: Convert java/awt/print/PrinterJob/PrinterDialogsModalityTest/PrinterDialogsModalityTest.html applet test to main Reviewed-by: prr, tr + test/jdk/java/awt/print/PrinterJob/PrinterDialogsModalityTest.java - test/jdk/java/awt/print/PrinterJob/PrinterDialogsModalityTest/PrinterDialogsModalityTest.html - test/jdk/java/awt/print/PrinterJob/PrinterDialogsModalityTest/PrinterDialogsModalityTest.java Changeset: 2725405a Author: Daniel Fuchs Date: 2024-03-26 20:04:30 +0000 URL: https://git.openjdk.org/leyden/commit/2725405ac9d93761e26812d010d315a48f86071c 8327991: Improve HttpClient documentation with regard to reclaiming resources Reviewed-by: michaelm, jpai ! src/java.net.http/share/classes/java/net/http/HttpClient.java ! src/java.net.http/share/classes/java/net/http/HttpResponse.java ! src/java.net.http/share/classes/java/net/http/package-info.java Changeset: 8fc9097b Author: Alex Menkov Date: 2024-03-26 23:54:28 +0000 URL: https://git.openjdk.org/leyden/commit/8fc9097b3720314ef7efaf1f3ac31898c8d6ca19 8315575: Retransform of record class with record component annotation fails with CFE Reviewed-by: sspitsyn, coleenp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/oops/recordComponent.cpp ! src/hotspot/share/oops/recordComponent.hpp ! src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp + test/jdk/java/lang/instrument/RetransformRecordAnnotation.java Changeset: 9e566d76 Author: Thomas Stuefe Date: 2024-03-27 08:36:40 +0000 URL: https://git.openjdk.org/leyden/commit/9e566d76d1d8acca27d8f69fffcbeb0b49b060ba 8327971: Multiple ASAN errors reported for metaspace 8327988: When running ASAN, disable dangerous NMT test Reviewed-by: jsjolen, rkennke ! src/hotspot/share/memory/metaspace/metachunk.cpp ! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp ! src/hotspot/share/nmt/mallocTracker.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/utilities/macros.hpp ! test/hotspot/gtest/metaspace/test_virtualspacenode.cpp ! test/hotspot/gtest/nmt/test_nmt_buffer_overflow_detection.cpp ! test/hotspot/gtest/nmt/test_nmt_cornercases.cpp ! test/hotspot/gtest/nmt/test_nmt_locationprinting.cpp Changeset: 4dfcc6df Author: Aggelos Biboudis Date: 2024-03-27 09:38:25 +0000 URL: https://git.openjdk.org/leyden/commit/4dfcc6df173d91b9b0b73d1ac3008e7cbb283871 8329115: Crash involving return from inner switch Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/langtools/tools/javac/patterns/T8329115.java + test/langtools/tools/javac/patterns/T8329115.out Changeset: 788d2bc4 Author: Albert Mingkun Yang Date: 2024-03-27 10:29:00 +0000 URL: https://git.openjdk.org/leyden/commit/788d2bc40c0340ae5d157c84ce9c101a25464785 8329169: Parallel: Remove unused local variable in MutableSpace::print_on Reviewed-by: tschatzl ! src/hotspot/share/gc/parallel/mutableSpace.cpp Changeset: 37a5a083 Author: Magnus Ihse Bursie Date: 2024-03-27 10:30:58 +0000 URL: https://git.openjdk.org/leyden/commit/37a5a08378fa686cda97357a0ad2632c359c98b9 8329102: Clean up jdk.jpackage native compilation Reviewed-by: erikj ! make/common/JdkNativeCompilation.gmk ! make/modules/jdk.jpackage/Lib.gmk Changeset: d0a26503 Author: Hannes Walln?fer Date: 2024-03-27 12:20:55 +0000 URL: https://git.openjdk.org/leyden/commit/d0a265039a36292d87b249af0e8977982e5acc7b 8324774: Add DejaVu web fonts 8327385: Add JavaDoc option to exclude web fonts from generated documentation Reviewed-by: ihse, jjg ! make/CompileInterimLangtools.gmk ! make/modules/jdk.javadoc/Java.gmk ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSans-Bold.woff + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSans-Bold.woff2 + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSans-BoldOblique.woff + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSans-BoldOblique.woff2 + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSans-Oblique.woff + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSans-Oblique.woff2 + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSans.woff + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSans.woff2 + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSansMono-Bold.woff + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSansMono-Bold.woff2 + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSansMono-BoldOblique.woff + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSansMono-BoldOblique.woff2 + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSansMono-Oblique.woff + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSansMono-Oblique.woff2 + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSansMono.woff + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSansMono.woff2 + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSerif-Bold.woff + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSerif-Bold.woff2 + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSerif-BoldItalic.woff + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSerif-BoldItalic.woff2 + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSerif-Italic.woff + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSerif-Italic.woff2 + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSerif.woff + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/DejaVuLGCSerif.woff2 + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/fonts/dejavu.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java + src/jdk.javadoc/share/legal/dejavufonts.md ! test/langtools/jdk/javadoc/doclet/checkLibraryVersions/CheckLibraryVersions.java + test/langtools/jdk/javadoc/doclet/testFonts/TestFonts.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/JavadocTester.java ! test/langtools/jdk/javadoc/testJavadocTester/TestJavadocTester.java ! test/langtools/jdk/javadoc/tool/CheckManPageOptions.java ! test/langtools/jdk/javadoc/tool/api/basic/APITest.java Changeset: d292aabf Author: Magnus Ihse Bursie Date: 2024-03-27 14:44:40 +0000 URL: https://git.openjdk.org/leyden/commit/d292aabf05edf41e14eca1976142f63c7b54779e 8329086: Clean up java.desktop native compilation Reviewed-by: erikj ! make/autoconf/lib-bundled.m4 ! make/autoconf/spec.gmk.template ! make/modules/java.desktop/Lib.gmk ! make/modules/java.desktop/lib/Awt2dLibraries.gmk ! make/modules/java.prefs/Lib.gmk Changeset: 614db2ea Author: Aleksey Shipilev Date: 2024-03-27 14:44:50 +0000 URL: https://git.openjdk.org/leyden/commit/614db2ea9e10346475eef34629eab54878aa482d 8328638: Fallback option for POST-only OCSP requests Reviewed-by: mullan, rhalade ! src/java.base/share/classes/sun/security/provider/certpath/OCSP.java ! test/jdk/java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java Changeset: 05854fd7 Author: Roland Westrelin Date: 2024-03-27 16:14:18 +0000 URL: https://git.openjdk.org/leyden/commit/05854fd704cba6ebd73007d9547a064891d49587 8329163: C2: possible overflow in PhaseIdealLoop::extract_long_range_checks() Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/loopnode.cpp Changeset: 892b8bb6 Author: Doug Simon Date: 2024-03-27 17:47:38 +0000 URL: https://git.openjdk.org/leyden/commit/892b8bb6d1725119e4c9ada8f2617c15f8af674e 8329189: runtime/stack/Stack016.java fails on libgraal Reviewed-by: never ! test/hotspot/jtreg/runtime/stack/Stack016.java Changeset: cc5b9c63 Author: Alisen Chung Date: 2024-03-27 19:18:52 +0000 URL: https://git.openjdk.org/leyden/commit/cc5b9c63cbc1743e22f80dce51d803e267c60317 8328227: Remove applet usage from JColorChooser tests Test4887836 Reviewed-by: honkar, prr - test/jdk/javax/swing/JColorChooser/Test4887836.html ! test/jdk/javax/swing/JColorChooser/Test4887836.java Changeset: e3588bba Author: Alisen Chung Date: 2024-03-27 19:19:51 +0000 URL: https://git.openjdk.org/leyden/commit/e3588bba0451d7d505b0e22d014842110677041b 8328819: Remove applet usage from JFileChooser tests bug6698013 Reviewed-by: honkar, tr, dnguyen - test/jdk/javax/swing/JFileChooser/6698013/bug6698013.html ! test/jdk/javax/swing/JFileChooser/6698013/bug6698013.java Changeset: 0cb0b5db Author: Justin Lu Date: 2024-03-27 21:13:28 +0000 URL: https://git.openjdk.org/leyden/commit/0cb0b5db2ac0f9b5a8fe40c5be5f7b12124fe402 8327875: ChoiceFormat should advise throwing UnsupportedOperationException for unused methods Reviewed-by: naoto ! src/java.base/share/classes/java/text/ChoiceFormat.java Changeset: 3eb1d05d Author: Vladimir Kozlov Date: 2024-03-27 21:56:53 +0000 URL: https://git.openjdk.org/leyden/commit/3eb1d05d853e92949bf239ac4b88436a4fe0997d 8328986: Deprecate UseRTM* flags for removal Co-authored-by: Roman Kennke Reviewed-by: vlivanov, sviswanathan, dholmes ! src/hotspot/cpu/x86/globals_x86.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/java.base/share/man/java.1 ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: 4fa77a2a Author: Guoxiong Li Date: 2024-03-28 04:03:16 +0000 URL: https://git.openjdk.org/leyden/commit/4fa77a2ad47a1a7c4064462c5c36e7710ec72549 8329096: G1: Change the type of G1BlockOffsetTable::_offset_base to uint8_t* Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp Changeset: d580bcf9 Author: Magnus Ihse Bursie Date: 2024-03-28 06:23:35 +0000 URL: https://git.openjdk.org/leyden/commit/d580bcf956d6e1e61aba142d7b639bc5ae26a17c 8329178: Clean up jdk.accessibility native compilation Reviewed-by: erikj, prr ! make/modules/jdk.accessibility/Launcher.gmk ! make/modules/jdk.accessibility/Lib.gmk Changeset: 47f33a59 Author: Thomas Stuefe Date: 2024-03-28 07:09:43 +0000 URL: https://git.openjdk.org/leyden/commit/47f33a59eaaffc74881fcc9e29d13ff9b2538c2a 8327986: ASAN reports use-after-free in DirectivesParserTest.empty_object_vm Reviewed-by: kvn, djelinski ! test/hotspot/gtest/compiler/test_directivesParser.cpp Changeset: 2b79c22c Author: Kevin Walls Date: 2024-03-28 09:06:41 +0000 URL: https://git.openjdk.org/leyden/commit/2b79c22c43a2de0815e77c9aa71f010906be8670 8327505: Test com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java fails Reviewed-by: lmesnik, stuefe ! test/jdk/com/sun/jmx/remote/NotificationMarshalVersions/Client/Client.java Changeset: 7c7b961e Author: Doug Simon Date: 2024-03-28 10:16:39 +0000 URL: https://git.openjdk.org/leyden/commit/7c7b961e732d1bef3c95a69758e283c8fb32fff6 8329191: JVMCI compiler warning is truncated Reviewed-by: never ! src/hotspot/share/jvmci/jvmciCompiler.cpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp Changeset: 2af0312c Author: Kevin Walls Date: 2024-03-28 11:34:44 +0000 URL: https://git.openjdk.org/leyden/commit/2af0312c958e693b1377f4c014ae8f84cabf6b83 8328619: sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed with BindException: Address already in use Reviewed-by: lmesnik, dfuchs ! test/jdk/sun/management/jmxremote/bootstrap/AbstractFilePermissionTest.java Changeset: aa595dbd Author: Erik ?sterlund Date: 2024-03-28 14:11:46 +0000 URL: https://git.openjdk.org/leyden/commit/aa595dbda4e64d76eeaff941b2f1e1ef2414d7af 8328507: Move StackWatermark code from safepoint cleanup Reviewed-by: aboldtch, coleenp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/x/xCollectedHeap.cpp ! src/hotspot/share/gc/x/xCollectedHeap.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/safepoint.hpp ! src/hotspot/share/runtime/stackWatermarkSet.cpp ! src/hotspot/share/runtime/stackWatermarkSet.hpp Changeset: 85cb4a99 Author: Calvin Cheung Date: 2024-03-28 15:03:09 +0000 URL: https://git.openjdk.org/leyden/commit/85cb4a9942f31ec99dae9f6a8af4f1fd4e8195bd 8247449: Revisit the argument processing logic for MetaspaceShared::disable_optimized_module_handling() Reviewed-by: iklam, matsaave ! src/hotspot/share/cds/cdsConfig.cpp ! src/hotspot/share/cds/cdsConfig.hpp ! src/hotspot/share/runtime/arguments.cpp Changeset: 7ac2f914 Author: Damon Nguyen Date: 2024-03-28 16:13:40 +0000 URL: https://git.openjdk.org/leyden/commit/7ac2f914aadf7fb12b7258e54efae959e15d6721 8329210: Delete Redundant Printer Dialog Modality Test Reviewed-by: honkar, prr - test/jdk/java/awt/print/Dialog/PrintModalDialog.java ! test/jdk/java/awt/print/PrinterJob/PrinterDialogsModalityTest.java Changeset: 341dd57f Author: Coleen Phillimore Date: 2024-03-28 19:30:55 +0000 URL: https://git.openjdk.org/leyden/commit/341dd57fa1393baadb3fec417a18ad0e981f8b0f 8325883: Move Monitor Deflation reporting out of safepoint cleanup Reviewed-by: eosterlund, dcubed ! src/hotspot/share/runtime/monitorDeflationThread.cpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! test/hotspot/jtreg/runtime/Monitor/MonitorUsedDeflationThresholdTest.java Changeset: 4eefda91 Author: Eirik Bj?rsn?s Date: 2024-03-28 20:00:07 +0000 URL: https://git.openjdk.org/leyden/commit/4eefda91021e07768ace03725c88a56af33ca344 8327779: Remove deprecated internal field sun.security.x509.X509Key.key Reviewed-by: mullan ! src/java.base/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/java.base/share/classes/sun/security/x509/X509Key.java Changeset: 991e04e7 Author: Fredrik Bredberg Committer: Coleen Phillimore Date: 2024-03-28 20:15:36 +0000 URL: https://git.openjdk.org/leyden/commit/991e04e7d7ff3ee682c2b8a9b860d325a176e7a5 8327383: Clean up _Stalled and _Spinner fields Reviewed-by: dholmes, coleenp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp Changeset: bf93e77e Author: Justin Lu Date: 2024-03-28 22:44:49 +0000 URL: https://git.openjdk.org/leyden/commit/bf93e77e72ccce56685fd10dde83587c703a37b3 8329118: Run MessageFormat additional subformat pattern tests under en_US locale Reviewed-by: naoto ! test/jdk/java/text/Format/MessageFormat/CompactSubFormats.java ! test/jdk/java/text/Format/MessageFormat/ListSubFormats.java Changeset: df01cc52 Author: Julian Waters Date: 2024-03-29 05:34:30 +0000 URL: https://git.openjdk.org/leyden/commit/df01cc528d3b6e52925b92119e43caee54ec86e8 8323576: [Windows] Fallthrough to ::abort instead of os::infinite_sleep for noreturn methods Reviewed-by: dholmes, kbarrett ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os/windows/vmError_windows.cpp Changeset: 245514da Author: Raphael Jolly Committer: Alexey Ivanov Date: 2024-03-29 10:07:14 +0000 URL: https://git.openjdk.org/leyden/commit/245514da51ef77757f530317e079a3f58370a0be 8328953: JEditorPane.read throws ChangedCharSetException Reviewed-by: tr, aivanov ! src/java.desktop/share/classes/javax/swing/JEditorPane.java + test/jdk/javax/swing/JEditorPane/EditorPaneCharset.java Changeset: 418deaf5 Author: Guoxiong Li Date: 2024-03-29 10:42:00 +0000 URL: https://git.openjdk.org/leyden/commit/418deaf5a1045d583ef9f5474d28dab31e2cfaf7 8328361: Use memset() in method CardTable::dirty_MemRegion() Reviewed-by: ayang, kbarrett ! src/hotspot/share/gc/shared/cardTable.cpp Changeset: 59c2aff1 Author: Weijun Wang Date: 2024-03-29 15:23:26 +0000 URL: https://git.openjdk.org/leyden/commit/59c2aff1edffb66762bbbe5e310913f87953be5b 8323624: ProviderList.ServiceList does not need to be a list Reviewed-by: mullan ! src/java.base/share/classes/java/security/KeyFactory.java ! src/java.base/share/classes/java/security/KeyPairGenerator.java ! src/java.base/share/classes/java/security/Signature.java ! src/java.base/share/classes/javax/crypto/Cipher.java ! src/java.base/share/classes/javax/crypto/JceSecurity.java.template ! src/java.base/share/classes/javax/crypto/KEM.java ! src/java.base/share/classes/javax/crypto/KeyAgreement.java ! src/java.base/share/classes/javax/crypto/KeyGenerator.java ! src/java.base/share/classes/javax/crypto/Mac.java ! src/java.base/share/classes/javax/crypto/SecretKeyFactory.java ! src/java.base/share/classes/sun/security/jca/GetInstance.java ! src/java.base/share/classes/sun/security/jca/ProviderList.java Changeset: 5b05f8e0 Author: Ioi Lam Date: 2024-03-29 16:01:54 +0000 URL: https://git.openjdk.org/leyden/commit/5b05f8e0c459d879b302728ce89c2012d198faec 8329112: Clean up CDS checking of unsupported module options Reviewed-by: ccheung, matsaave ! src/hotspot/share/cds/cdsConfig.cpp ! src/hotspot/share/cds/cdsConfig.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/classLoader.cpp Changeset: 8a0ef811 Author: Naoto Sato Date: 2024-03-29 17:55:57 +0000 URL: https://git.openjdk.org/leyden/commit/8a0ef811ed4daaa611c9578db0b7fcbcfb57643d 8326627: Document Double/Float.valueOf(String) behavior for numeric strings with non-ASCII digits Reviewed-by: iris, jlu ! src/java.base/share/classes/java/lang/Double.java ! src/java.base/share/classes/java/lang/Float.java ! test/jdk/java/lang/Double/ParseDouble.java ! test/jdk/java/lang/Float/ParseFloat.java Changeset: d1b51e39 Author: Calvin Cheung Date: 2024-03-29 18:05:21 +0000 URL: https://git.openjdk.org/leyden/commit/d1b51e39c952df4885a424afd01161c601ef0f72 8321550: Update several runtime/cds tests to use vm flags or mark as flagless Reviewed-by: matsaave, iklam ! test/hotspot/jtreg/runtime/cds/TestCDSVMCrash.java ! test/hotspot/jtreg/runtime/cds/appcds/FillerObjectLoadTest.java ! test/hotspot/jtreg/runtime/cds/appcds/TestDumpClassListSource.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/ResolvedReferencesNotNullTest.java Changeset: 20cb6e78 Author: Phil Race Date: 2024-03-29 18:08:11 +0000 URL: https://git.openjdk.org/leyden/commit/20cb6e786fbf6d924c509e28d6fded86d61a5f84 8329337: Problem list BufferStrategyExceptionTest.java on Windows Reviewed-by: dcubed, aivanov ! test/jdk/ProblemList.txt Changeset: 37c22791 Author: Ioi Lam Date: 2024-03-30 02:17:45 +0000 URL: https://git.openjdk.org/leyden/commit/37c2279148fa91627137e3af362bfcffde61acd0 8329150: Remove CDS support for LatestMethodCache Reviewed-by: coleenp, matsaave ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp Changeset: f2e5808b Author: Volker Simonis Date: 2024-03-30 12:47:51 +0000 URL: https://git.openjdk.org/leyden/commit/f2e5808b46a3da6920dd56688c877ee0e2795de6 8329126: No native wrappers generated anymore with -XX:-TieredCompilation after JDK-8251462 Reviewed-by: kvn, iveresov, vlivanov ! src/hotspot/share/compiler/compilationPolicy.cpp + test/hotspot/jtreg/compiler/calls/NativeCalls.java + test/hotspot/jtreg/compiler/calls/libNativeCalls.c Changeset: 9d052e93 Author: Magnus Ihse Bursie Date: 2024-03-31 11:15:49 +0000 URL: https://git.openjdk.org/leyden/commit/9d052e93314f7fa50b356e368faa5ea723d3df54 8329131: Fold libjli_static back into libjli on AIX Reviewed-by: erikj, clanger ! make/common/JdkNativeCompilation.gmk ! make/common/NativeCompilation.gmk ! make/common/modules/LauncherCommon.gmk ! make/common/native/Link.gmk ! make/common/native/LinkMicrosoft.gmk ! make/modules/java.base/lib/CoreLibraries.gmk ! make/modules/java.instrument/Lib.gmk ! make/test/JtregNativeJdk.gmk Changeset: 1e76e1fd Author: Alisen Chung Date: 2024-04-01 06:22:11 +0000 URL: https://git.openjdk.org/leyden/commit/1e76e1fdfa67c28ce20b0dc7fb0253670be54554 8328403: Remove applet usage from JColorChooser tests Test6977726 Reviewed-by: tr, honkar - test/jdk/javax/swing/JColorChooser/Test6977726.html ! test/jdk/javax/swing/JColorChooser/Test6977726.java Changeset: 3f5b75a5 Author: Prasanta Sadhukhan Date: 2024-04-01 12:58:44 +0000 URL: https://git.openjdk.org/leyden/commit/3f5b75a5ef1606ee9ee0fcefaafcf4a8941788b4 8328541: Remove or update obsolete comment in JRootPane Reviewed-by: aivanov, abhiscxk ! src/java.desktop/share/classes/javax/swing/JRootPane.java Changeset: 9f5464ee Author: Calvin Cheung Date: 2024-04-01 17:03:48 +0000 URL: https://git.openjdk.org/leyden/commit/9f5464ee95044c848cd859f173859d08e2248a95 8329353: ResolvedReferencesNotNullTest.java failed with Incorrect resolved references array, quxString should not be archived Reviewed-by: iklam ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/ResolvedReferencesNotNullTest.java Changeset: 4a14cba2 Author: Aleksey Shipilev Date: 2024-04-01 17:27:00 +0000 URL: https://git.openjdk.org/leyden/commit/4a14cba2f1632c5cb91e37a07638ea6d8ad4ec00 8329213: Better validation for com.sun.security.ocsp.useget option Reviewed-by: mullan ! src/java.base/share/classes/sun/security/action/GetPropertyAction.java ! src/java.base/share/classes/sun/security/provider/certpath/OCSP.java ! test/jdk/java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java ! test/jdk/java/security/testlibrary/SimpleOCSPServer.java Changeset: 5698f7ad Author: Aleksey Shipilev Date: 2024-04-01 17:27:10 +0000 URL: https://git.openjdk.org/leyden/commit/5698f7ad29c939b7e52882ace575dd7113bf41de 8329134: Reconsider TLAB zapping Reviewed-by: stefank, rkennke ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: c2979c15 Author: Daniel D. Daugherty Date: 2024-04-01 22:20:47 +0000 URL: https://git.openjdk.org/leyden/commit/c2979c150bdbcc2a9e6026347dc590e6a7e86595 8329425: ProblemList containers/docker/TestJFREvents.java on linux-x64 8329426: ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on windows-x64 8329427: ProblemList javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64 8329428: ProblemList vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp Reviewed-by: dholmes ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList.txt Changeset: ecd2b711 Author: Jie Fu Date: 2024-04-01 23:02:48 +0000 URL: https://git.openjdk.org/leyden/commit/ecd2b7112a7617b11997da341d6185756bf1fb0f 8329354: java/text/Format/MessageFormat/CompactSubFormats.java fails Reviewed-by: jlu, naoto ! test/jdk/java/text/Format/MessageFormat/CompactSubFormats.java Changeset: 70c8ff1c Author: Serguei Spitsyn Date: 2024-04-01 23:37:07 +0000 URL: https://git.openjdk.org/leyden/commit/70c8ff1c9a9adf21a16d8a6b4da1eeec65afe61d 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout Reviewed-by: lmesnik, cjplummer ! test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/libPopFrameTest.cpp Changeset: a85c8493 Author: Jaikiran Pai Date: 2024-04-02 01:14:35 +0000 URL: https://git.openjdk.org/leyden/commit/a85c8493aec73e81c000ea3e3d983b05706bbfec 8328273: sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java failed with java.rmi.server.ExportException: Port already in use Reviewed-by: dcubed ! test/jdk/javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java ! test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java Changeset: d3fc8df8 Author: Ioi Lam Date: 2024-04-02 01:54:28 +0000 URL: https://git.openjdk.org/leyden/commit/d3fc8df8af11d7cc1cc341bc75e46b7e93d6db31 8329135: Store Universe::*exception_instance() in CDS archive Reviewed-by: vlivanov, ccheung ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp Changeset: af7c6af0 Author: Renjith Kannath Pariyangad Committer: Phil Race Date: 2024-04-02 04:28:50 +0000 URL: https://git.openjdk.org/leyden/commit/af7c6af0cc1eb6c42199c05933c7feb032bd6353 8324808: Manual printer tests have no Pass/Fail buttons, instructions close set 3 Reviewed-by: tr, achung, aivanov ! test/jdk/java/awt/print/PrinterJob/PageDlgPrnButton.java ! test/jdk/java/awt/print/PrinterJob/PrintCompoundString.java ! test/jdk/java/awt/print/PrinterJob/PrintImage.java ! test/jdk/java/awt/print/PrinterJob/PrintNullString.java ! test/jdk/java/awt/print/PrinterJob/PrintParenString.java ! test/jdk/java/awt/print/PrinterJob/PrintTranslatedFont.java Changeset: bc546c21 Author: Phil Race Date: 2024-04-02 04:29:02 +0000 URL: https://git.openjdk.org/leyden/commit/bc546c21a59d2481ba86f98d0d653c7691f68d4c 8328561: test java/awt/Robot/ManualInstructions/ManualInstructions.java isn't used Reviewed-by: dnguyen, psadhukhan - test/jdk/java/awt/Robot/ManualInstructions/ManualInstructions.java Changeset: 6b1b0e9d Author: Andrei Pangin Committer: Serguei Spitsyn Date: 2024-04-02 04:30:26 +0000 URL: https://git.openjdk.org/leyden/commit/6b1b0e9d45eb56f88398e2a6bca0d90c03112eaa 8329103: assert(!thread->in_asgct()) failed during multi-mode profiling Reviewed-by: dholmes, sspitsyn ! src/hotspot/share/runtime/thread.hpp Changeset: 5cddc2de Author: Emanuel Peter Date: 2024-04-02 06:10:08 +0000 URL: https://git.openjdk.org/leyden/commit/5cddc2de493d9d8712e4bee3aed4f1a0d4c228c3 8325252: C2 SuperWord: refactor the packset Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/superword.hpp ! src/hotspot/share/opto/vectorization.hpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp ! test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java Changeset: 3d228380 Author: Kim Barrett Date: 2024-04-02 06:57:43 +0000 URL: https://git.openjdk.org/leyden/commit/3d2283800acee58dbf046c8b401a5a144ab65ed1 8328997: Remove unnecessary template parameter lists in GrowableArray Reviewed-by: iwalulya, epeter ! src/hotspot/share/utilities/growableArray.hpp Changeset: 816638e3 Author: Man Cao Date: 2024-04-02 07:26:18 +0000 URL: https://git.openjdk.org/leyden/commit/816638e3bedef9f57c438dfd2f9837acbb93ff90 8329352: Remove dead code in splashscreen_sys.c Reviewed-by: jiefu, prr ! src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c Changeset: 3b582dff Author: Sean Coffey Date: 2024-04-02 08:51:13 +0000 URL: https://git.openjdk.org/leyden/commit/3b582dff849f1c25336e2efc415eb121f8b12189 8051959: Add thread and timestamp options to java.security.debug system property Reviewed-by: mullan, weijun ! src/java.base/share/classes/sun/security/util/Debug.java ! test/jdk/sun/security/krb5/auto/LoginModuleDebug.java + test/jdk/sun/security/util/Debug/DebugOptions.java Changeset: 8b934aab Author: Guoxiong Li Date: 2024-04-02 10:14:04 +0000 URL: https://git.openjdk.org/leyden/commit/8b934aab1402ea74ac1fb7b56bfb9840f932ccb1 8329358: Generational ZGC: Remove the unused method ZPointer::set_remset_bits Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zAddress.hpp ! src/hotspot/share/gc/z/zAddress.inline.hpp Changeset: 5cf457b7 Author: Alexey Ivanov Date: 2024-04-02 10:31:38 +0000 URL: https://git.openjdk.org/leyden/commit/5cf457b74334c08bab40e2e6c1a8544a2555fb82 8329320: Simplify awt/print/PageFormat/NullPaper.java test Reviewed-by: honkar, prr ! test/jdk/java/awt/print/PageFormat/NullPaper.java Changeset: ed821cbe Author: Renjith Kannath Pariyangad Committer: Alexey Ivanov Date: 2024-04-02 11:26:04 +0000 URL: https://git.openjdk.org/leyden/commit/ed821cbe857363e049f3c640ae4546c340a577ac 8324807: Manual printer tests have no Pass/Fail buttons, instructions close set 2 Reviewed-by: tr, achung, aivanov ! test/jdk/java/awt/print/PrinterJob/Collate2DPrintingTest.java ! test/jdk/java/awt/print/PrinterJob/DrawImage.java ! test/jdk/java/awt/print/PrinterJob/DrawStringMethods.java ! test/jdk/java/awt/print/PrinterJob/InvalidPage.java ! test/jdk/java/awt/print/PrinterJob/JobName/PrinterJobName.java ! test/jdk/java/awt/print/PrinterJob/NumCopies.java Changeset: 5ae849d6 Author: Magnus Ihse Bursie Date: 2024-04-02 13:09:53 +0000 URL: https://git.openjdk.org/leyden/commit/5ae849d66f195e96fbae9dcf06a44d8aab659181 8329292: Fix missing cleanups in java.management and jdk.management Reviewed-by: erikj ! make/modules/java.management/Lib.gmk ! make/modules/jdk.management/Lib.gmk Changeset: 5ac067f6 Author: Magnus Ihse Bursie Date: 2024-04-02 13:15:56 +0000 URL: https://git.openjdk.org/leyden/commit/5ac067f6d6e0b301b33fb287aa3f288d318df2ba 8329289: Unify SetupJdkExecutable and SetupJdkLibrary Reviewed-by: erikj ! make/common/JdkNativeCompilation.gmk Changeset: 7eb78e33 Author: Renjith Kannath Pariyangad Committer: Alexey Ivanov Date: 2024-04-02 13:22:17 +0000 URL: https://git.openjdk.org/leyden/commit/7eb78e332080df3890b66ca04338a4ba69af45eb 8320676: Manual printer tests have no Pass/Fail buttons, instructions close set 1 Reviewed-by: honkar, achung, aivanov ! test/jdk/java/awt/print/PageFormat/PageSetupDialog.java ! test/jdk/java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java ! test/jdk/java/awt/print/PrinterJob/PrintAllFonts.java ! test/jdk/java/awt/print/PrinterJob/ValidatePage/ValidatePage.java ! test/jdk/java/awt/print/PrinterJob/raster/RasterTest.java Changeset: 6ae1cf12 Author: Guoxiong Li Date: 2024-04-02 15:08:12 +0000 URL: https://git.openjdk.org/leyden/commit/6ae1cf12cee268ac7599eb9ade9c0861a89748f9 8329368: Generational ZGC: Remove the unnecessary friend classes in ZAllocator Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zAllocator.hpp Changeset: dd5d7d07 Author: Brian Burkhalter Date: 2024-04-02 17:13:04 +0000 URL: https://git.openjdk.org/leyden/commit/dd5d7d0770609a414438041f40a69f8770afe25c 8327002: (fs) java/nio/file/Files/CopyMoveVariations.java should be able to test across file systems Reviewed-by: alanb ! test/jdk/java/nio/file/Files/CopyMoveVariations.java Changeset: 925d8293 Author: Sean Coffey Date: 2024-04-02 17:32:31 +0000 URL: https://git.openjdk.org/leyden/commit/925d82931c09dc11ea5a3bc410ea5cfd67ee14aa 8329013: StackOverflowError when starting Apache Tomcat with signed jar Reviewed-by: dfuchs, jpai ! src/java.base/share/classes/jdk/internal/event/EventHelper.java + test/jdk/jdk/security/logging/RecursiveEventHelper.java Changeset: db159149 Author: Harshitha Onkar Date: 2024-04-02 18:13:33 +0000 URL: https://git.openjdk.org/leyden/commit/db159149c1c13a98ee9a85750741c6a3cd39f408 8328753: Open source few Undecorated Frame tests Reviewed-by: abhiscxk, dnguyen, prr, aivanov + test/jdk/java/awt/Frame/FrameDialogMixedTest.java + test/jdk/java/awt/Frame/MaximizeUndecoratedTest.java + test/jdk/java/awt/Frame/MinimizeUndecoratedTest.java Changeset: 3057dded Author: Volker Simonis Date: 2024-04-02 19:52:01 +0000 URL: https://git.openjdk.org/leyden/commit/3057dded4878b0110bc2c09b52019570a0a31c9f 8329421: Native methods can not be selectively printed Reviewed-by: kvn ! src/hotspot/share/runtime/sharedRuntime.cpp ! test/hotspot/jtreg/compiler/calls/NativeCalls.java Changeset: b298683e Author: iklam Date: 2024-04-02 14:57:03 +0000 URL: https://git.openjdk.org/leyden/commit/b298683efa5047b0a27d53331d7ab01bb70d930a Merge branch 'master' of https://github.com/openjdk/leyden into premain ! src/hotspot/share/cds/cdsConfig.cpp ! src/hotspot/share/cds/cdsConfig.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/klassFactory.cpp ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/jvmci/jvmciCompiler.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/unsafe.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/cds/cdsConfig.cpp ! src/hotspot/share/cds/cdsConfig.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/klassFactory.cpp ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/jvmci/jvmciCompiler.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/unsafe.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/thread.hpp From duke at openjdk.org Thu Apr 4 04:02:58 2024 From: duke at openjdk.org (duke) Date: Thu, 4 Apr 2024 04:02:58 GMT Subject: git: openjdk/leyden: premain: Fixed crashing with https://github.com/sdeleuze/petclinic-efficient-container Message-ID: Changeset: a81c1cc9 Author: iklam Date: 2024-04-03 21:02:31 +0000 URL: https://git.openjdk.org/leyden/commit/a81c1cc957689499a47c50a72f2cab74add90075 Fixed crashing with https://github.com/sdeleuze/petclinic-efficient-container ! src/hotspot/share/cds/cdsConfig.cpp From duke at openjdk.org Fri Apr 5 00:30:13 2024 From: duke at openjdk.org (duke) Date: Fri, 5 Apr 2024 00:30:13 GMT Subject: git: openjdk/leyden: premain: 35 new changesets Message-ID: <53725997-0113-4e5c-9cad-265f754ecca3@openjdk.org> Changeset: 021ed6ae Author: Alisen Chung Date: 2024-04-02 23:36:05 +0000 URL: https://git.openjdk.org/leyden/commit/021ed6aea92f770ebeae65175d94797f7c418c82 8328648: Remove applet usage from JFileChooser tests bug4150029 Reviewed-by: dnguyen, abhiscxk, honkar - test/jdk/javax/swing/JFileChooser/4150029/bug4150029.html ! test/jdk/javax/swing/JFileChooser/4150029/bug4150029.java Changeset: f88f31dc Author: Alex Menkov Date: 2024-04-03 00:23:36 +0000 URL: https://git.openjdk.org/leyden/commit/f88f31dcbf80e9a4cd3ba9d34be8b88128af97c6 8328137: PreserveAllAnnotations can cause failure of class retransformation Reviewed-by: coleenp, sspitsyn ! src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp ! src/hotspot/share/prims/jvmtiClassFileReconstituter.hpp ! test/jdk/java/lang/instrument/RetransformRecordAnnotation.java Changeset: 866e7b6b Author: Quan Zhang Committer: Vladimir Kozlov Date: 2024-04-03 00:32:33 +0000 URL: https://git.openjdk.org/leyden/commit/866e7b6b7745928e559da8cdf622bf6a097ec995 8329174: update CodeBuffer layout in comment after constants section moved Reviewed-by: kvn ! src/hotspot/share/asm/codeBuffer.cpp Changeset: 92f5c0be Author: Daniel Lund?n Committer: Tobias Hartmann Date: 2024-04-03 05:50:41 +0000 URL: https://git.openjdk.org/leyden/commit/92f5c0be8e3b47343b54a26940df691faaf49b23 8323682: C2: guard check is not generated in Arrays.copyOfRange intrinsic when allocation is eliminated by EA Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/macroArrayCopy.cpp + test/hotspot/jtreg/compiler/arraycopy/TestArrayCopyOfRangeGuards.java Changeset: 16b842af Author: Fei Yang Date: 2024-04-03 07:39:24 +0000 URL: https://git.openjdk.org/leyden/commit/16b842af8edd10c4071eec98caf838a2f6c49746 8329355: Test compiler/c2/irTests/TestIfMinMax.java fails on RISC-V Reviewed-by: jkarthikeyan, thartmann, chagedorn ! test/hotspot/jtreg/compiler/c2/irTests/TestIfMinMax.java Changeset: e3e6c2a8 Author: Guoxiong Li Date: 2024-04-03 07:49:56 +0000 URL: https://git.openjdk.org/leyden/commit/e3e6c2a8991fbc4f56e051e9abe004f0aa5674a0 8328278: Do not print the tenuring threshold in AgeTable::print_on Reviewed-by: ayang, ysr ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/shared/ageTable.cpp ! src/hotspot/share/gc/shared/ageTable.hpp ! test/hotspot/jtreg/gc/TestAgeOutput.java Changeset: bdd9438b Author: Stefan Karlsson Date: 2024-04-03 08:58:41 +0000 URL: https://git.openjdk.org/leyden/commit/bdd9438b453fedf9b8181ad2615640168638677d 8328647: TestGarbageCollectorMXBean.java fails with C1-only and -Xcomp Reviewed-by: jiefu, tschatzl, lmesnik ! test/hotspot/jtreg/gc/x/TestGarbageCollectorMXBean.java ! test/hotspot/jtreg/gc/z/TestGarbageCollectorMXBean.java Changeset: d954f3bd Author: Albert Mingkun Yang Date: 2024-04-03 10:16:31 +0000 URL: https://git.openjdk.org/leyden/commit/d954f3bd0c918d3583207e522907923a087f8708 8329493: Parallel: Remove unused ParallelArguments::heap_max_size_bytes Reviewed-by: sjohanss ! src/hotspot/share/gc/parallel/parallelArguments.cpp ! src/hotspot/share/gc/parallel/parallelArguments.hpp Changeset: 80c54b48 Author: Albert Mingkun Yang Date: 2024-04-03 10:30:19 +0000 URL: https://git.openjdk.org/leyden/commit/80c54b484f89be9d26066da94ada55bcd3d03fdc 8328932: Parallel: Proper partial object setup in fill_dense_prefix_end Reviewed-by: tschatzl, gli ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: bea493bc Author: Coleen Phillimore Date: 2024-04-03 12:21:11 +0000 URL: https://git.openjdk.org/leyden/commit/bea493bcb86370dc3fb00d86c545f01fc614e000 8236736: Change notproduct JVM flags to develop flags Reviewed-by: iklam, kvn, kbarrett ! src/hotspot/cpu/aarch64/globals_aarch64.hpp ! src/hotspot/cpu/arm/globals_arm.hpp ! src/hotspot/cpu/ppc/globals_ppc.hpp ! src/hotspot/cpu/riscv/globals_riscv.hpp ! src/hotspot/cpu/s390/globals_s390.hpp ! src/hotspot/cpu/x86/globals_x86.hpp ! src/hotspot/cpu/zero/globals_zero.hpp ! src/hotspot/os/aix/globals_aix.hpp ! src/hotspot/os/bsd/globals_bsd.hpp ! src/hotspot/os/linux/globals_linux.hpp ! src/hotspot/os/windows/globals_windows.hpp ! src/hotspot/share/c1/c1_globals.hpp ! src/hotspot/share/cds/cds_globals.hpp ! src/hotspot/share/compiler/compiler_globals.hpp ! src/hotspot/share/gc/epsilon/epsilon_globals.hpp ! src/hotspot/share/gc/g1/g1_globals.hpp ! src/hotspot/share/gc/parallel/parallel_globals.hpp ! src/hotspot/share/gc/serial/serial_globals.hpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/gc/shared/tlab_globals.hpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp ! src/hotspot/share/gc/x/x_globals.hpp ! src/hotspot/share/gc/z/shared/z_shared_globals.hpp ! src/hotspot/share/gc/z/z_globals.hpp ! src/hotspot/share/jvmci/jvmci_globals.cpp ! src/hotspot/share/jvmci/jvmci_globals.hpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/flags/allFlags.hpp ! src/hotspot/share/runtime/flags/debug_globals.hpp ! src/hotspot/share/runtime/flags/jvmFlag.cpp ! src/hotspot/share/runtime/flags/jvmFlag.hpp ! src/hotspot/share/runtime/flags/jvmFlagLimit.cpp ! src/hotspot/share/runtime/flags/jvmFlagLookup.cpp ! src/hotspot/share/runtime/globals.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/globals_extension.hpp ! src/hotspot/share/runtime/globals_shared.hpp ! src/hotspot/share/services/management.cpp ! test/hotspot/jtreg/compiler/jvmci/compilerToVM/GetFlagValueTest.java ! test/hotspot/jtreg/runtime/CommandLine/IgnoreUnrecognizedVMOptions.java ! test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java ! test/hotspot/jtreg/runtime/CommandLine/VMOptionWarning.java Changeset: ee09801a Author: Guoxiong Li Date: 2024-04-03 15:22:01 +0000 URL: https://git.openjdk.org/leyden/commit/ee09801afde55844e3bc9d0ea9eea065280de0b7 8328352: Serial: Inline SerialBlockOffsetSharedArray Reviewed-by: ayang, aboldtch ! src/hotspot/share/gc/serial/serialBlockOffsetTable.cpp ! src/hotspot/share/gc/serial/serialBlockOffsetTable.hpp ! src/hotspot/share/gc/serial/serialBlockOffsetTable.inline.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp ! src/hotspot/share/gc/serial/vmStructs_serial.hpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/space.hpp ! src/hotspot/share/gc/shared/space.inline.hpp Changeset: 1c691938 Author: Vicente Romero Date: 2024-04-03 15:55:37 +0000 URL: https://git.openjdk.org/leyden/commit/1c691938e98a2dd825f20b58a0032b6a0c9b03b2 8328383: Method is not used: com.sun.tools.javac.comp.Attr::thisSym Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Changeset: 8dc43aa0 Author: Vicente Romero Date: 2024-04-03 15:56:44 +0000 URL: https://git.openjdk.org/leyden/commit/8dc43aa0fe8cdba2a2953258de02c6afa072987a 8325217: MethodSymbol.getModifiers() returns SEALED for restricted methods Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! test/langtools/jdk/javadoc/doclet/testRestricted/TestRestricted.java Changeset: 023f7f17 Author: Mikael Vidstedt Date: 2024-04-03 16:25:55 +0000 URL: https://git.openjdk.org/leyden/commit/023f7f176b32ffa38dd599ea110c2b9c18886b74 8320799: Bump minimum boot jdk to JDK 22 Reviewed-by: iris, erikj, ihse ! make/conf/github-actions.conf ! make/conf/jib-profiles.js ! make/conf/version-numbers.conf Changeset: 233619b3 Author: Joe Darcy Date: 2024-04-03 16:29:23 +0000 URL: https://git.openjdk.org/leyden/commit/233619b3fb2916ca6216f9d16f70fedf35837a43 8329557: Fix statement around MathContext.DECIMAL128 rounding Reviewed-by: bpb, iris, rgiulietti ! src/java.base/share/classes/java/math/MathContext.java Changeset: 375bfac8 Author: Bill Huang Date: 2024-04-03 17:04:09 +0000 URL: https://git.openjdk.org/leyden/commit/375bfac8e7ff3f871e2d986876f91a5fba200c83 8327474: Review use of java.io.tmpdir in jdk tests Reviewed-by: michaelm, jpai ! test/jdk/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java ! test/jdk/java/io/File/CheckPermission.java ! test/jdk/java/io/FileInputStream/NegativeAvailable.java ! test/jdk/java/nio/channels/unixdomain/Bind.java ! test/jdk/java/nio/channels/unixdomain/NonBlockingAccept.java ! test/jdk/java/util/zip/ZipFile/ZeroDate.java ! test/jdk/jdk/jfr/api/consumer/filestream/TestOrdered.java ! test/jdk/jdk/jfr/api/consumer/filestream/TestReuse.java ! test/jdk/jdk/jfr/threading/TestManyVirtualThreads.java ! test/jdk/jdk/nio/zipfs/ZeroDate.java ! test/jdk/sun/security/pkcs12/P12SecretKey.java Changeset: 16576b87 Author: Matthew Donovan Date: 2024-04-03 17:17:12 +0000 URL: https://git.openjdk.org/leyden/commit/16576b87b7267aaa99c41f77993287e3479577aa 8328957: Update PKCS11Test.java to not use hardcoded path Reviewed-by: mbalao, rhalade ! test/jdk/sun/security/pkcs11/PKCS11Test.java Changeset: 8267d656 Author: Tomas Zezula Committer: Doug Simon Date: 2024-04-03 20:10:50 +0000 URL: https://git.openjdk.org/leyden/commit/8267d6565d17c8db8f5b50a37482610ffe0a8a5c 8329564: [JVMCI] TranslatedException::debugPrintStackTrace does not work in the libjvmci compiler. Reviewed-by: dnsimon ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/java.base/share/classes/jdk/internal/vm/TranslatedException.java ! src/java.base/share/classes/jdk/internal/vm/VMSupport.java ! test/jdk/jdk/internal/vm/TestTranslatedException.java Changeset: 80201830 Author: Ioi Lam Date: 2024-04-03 21:45:55 +0000 URL: https://git.openjdk.org/leyden/commit/802018306f6c06815c4706e711eebd0892c4657a 8329470: Remove obsolete CDS SharedStrings tests Reviewed-by: ccheung - test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/LockSharedStrings.java - test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/LockStringTest.java - test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/LockStringValueTest.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsStress.java Changeset: 41966885 Author: Guoxiong Li Date: 2024-04-04 03:42:12 +0000 URL: https://git.openjdk.org/leyden/commit/41966885b9c0b71bf34431714702a8245ce3130b 8329494: Serial: Merge GenMarkSweep into MarkSweep Reviewed-by: ihse, ayang, tschatzl ! make/hotspot/lib/JvmFeatures.gmk - src/hotspot/share/gc/serial/genMarkSweep.cpp - src/hotspot/share/gc/serial/genMarkSweep.hpp ! src/hotspot/share/gc/serial/markSweep.cpp ! src/hotspot/share/gc/serial/markSweep.hpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp Changeset: 29314587 Author: Emanuel Peter Date: 2024-04-04 05:01:30 +0000 URL: https://git.openjdk.org/leyden/commit/2931458711244e20eb7845a1aefcf6ed4206bce1 8328938: C2 SuperWord: disable vectorization for large stride and scale Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/vectorization.cpp + test/hotspot/jtreg/compiler/loopopts/superword/TestLargeScaleAndStride.java Changeset: f762637b Author: Emanuel Peter Date: 2024-04-04 05:11:59 +0000 URL: https://git.openjdk.org/leyden/commit/f762637be2568f898db25aa6a57c180f1feac3a3 8326962: C2 SuperWord: cache VPointer Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/superword.hpp ! src/hotspot/share/opto/traceAutoVectorizationTag.hpp ! src/hotspot/share/opto/vectorization.cpp ! src/hotspot/share/opto/vectorization.hpp Changeset: e5e21a8a Author: Christian Hagedorn Date: 2024-04-04 06:02:35 +0000 URL: https://git.openjdk.org/leyden/commit/e5e21a8a6e64466f9cda2064aa2723a15d4ae86a 8328702: C2: Crash during parsing because sub type check is not folded Reviewed-by: roland, kvn ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/type.cpp + test/hotspot/jtreg/compiler/types/TestSubTypeCheckWithBottomArray.java Changeset: f26e4308 Author: Christian Hagedorn Date: 2024-04-04 06:04:49 +0000 URL: https://git.openjdk.org/leyden/commit/f26e4308992d989d71e7fbfaa3feb95f0ea17c06 8327110: Refactor create_bool_from_template_assertion_predicate() to separate class and fix identical cloning cases used for Loop Unswitching and Split If Reviewed-by: epeter, kvn ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/opaquenode.hpp ! src/hotspot/share/opto/predicates.cpp ! src/hotspot/share/opto/predicates.hpp ! src/hotspot/share/opto/split_if.cpp + test/hotspot/jtreg/compiler/predicates/TestCloningWithManyDiamondsInExpression.java Changeset: 8efd7aa6 Author: Matthias Baesken Date: 2024-04-04 07:48:48 +0000 URL: https://git.openjdk.org/leyden/commit/8efd7aa6c1671fa7d40c5c43bed140a493cfcf72 8328786: [AIX] move some important warnings/errors from trcVerbose to UL Reviewed-by: lucy, stuefe ! src/hotspot/os/aix/libperfstat_aix.cpp ! src/hotspot/os/aix/loadlib_aix.cpp ! src/hotspot/os/aix/os_aix.cpp Changeset: a169c063 Author: Albert Mingkun Yang Date: 2024-04-04 08:03:52 +0000 URL: https://git.openjdk.org/leyden/commit/a169c0636182272ff3f2a7cfe2212fec1af3fda9 8329580: Parallel: Remove VerifyObjectStartArray Reviewed-by: tschatzl, gli ! src/hotspot/share/gc/parallel/psOldGen.cpp ! src/hotspot/share/gc/parallel/psOldGen.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! test/hotspot/jtreg/gc/g1/TestVerificationInConcurrentCycle.java Changeset: b9da1401 Author: Ivan Walulya Date: 2024-04-04 08:15:41 +0000 URL: https://git.openjdk.org/leyden/commit/b9da14012da5f1f72d4f6e690c18a43e87523173 8329594: G1: Consistent Titles to Thread Work Items. Reviewed-by: tschatzl, gli ! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp Changeset: 21867c92 Author: Coleen Phillimore Date: 2024-04-04 13:15:12 +0000 URL: https://git.openjdk.org/leyden/commit/21867c929a2f2c961148f2cd1e79d672ac278d27 8313332: Simplify lazy jmethodID cache in InstanceKlass Reviewed-by: amenkov, sspitsyn, dcubed ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/runtime/vmStructs.cpp Changeset: f3db2796 Author: Fredrik Bredberg Committer: Jesper Wilhelmsson Date: 2024-04-04 15:28:46 +0000 URL: https://git.openjdk.org/leyden/commit/f3db2796b875ee9177b111a0f3da3b9566d750d6 8327410: Add hostname option for UL file names Reviewed-by: jsjolen, dholmes ! src/hotspot/share/logging/logConfiguration.cpp ! src/hotspot/share/logging/logFileOutput.cpp ! src/hotspot/share/logging/logFileOutput.hpp ! src/java.base/share/man/java.1 Changeset: d90e5b5b Author: Kim Barrett Date: 2024-04-04 16:45:32 +0000 URL: https://git.openjdk.org/leyden/commit/d90e5b5b9f235cfcfc635d107e8d73cd2ce35f51 8329546: Assume sized integral types are available Reviewed-by: iklam, jwaters ! src/hotspot/share/utilities/globalDefinitions_gcc.hpp Changeset: 6382a129 Author: Kevin Walls Date: 2024-04-04 16:54:11 +0000 URL: https://git.openjdk.org/leyden/commit/6382a1290fbd7cc8fd097a2972bfcfc06fa4de79 8326666: Remove the Java Management Extension (JMX) Subject Delegation feature Reviewed-by: mchung, dfuchs ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl_Stub.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ClientListenerInfo.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java - src/java.management/share/classes/com/sun/jmx/remote/security/SubjectDelegator.java ! src/java.management/share/classes/javax/management/remote/JMXConnector.java ! test/jdk/ProblemList-Virtual.txt ! test/jdk/ProblemList.txt + test/jdk/javax/management/remote/mandatory/RemovedSubjectDelegation.java - test/jdk/javax/management/remote/mandatory/connection/RMIConnectorInternalMapTest.java ! test/jdk/javax/management/remote/mandatory/notif/DeadListenerTest.java - test/jdk/javax/management/remote/mandatory/subjectDelegation/SimpleStandard.java - test/jdk/javax/management/remote/mandatory/subjectDelegation/SimpleStandardMBean.java - test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java - test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java - test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java - test/jdk/javax/management/remote/mandatory/subjectDelegation/jmxremote.password - test/jdk/javax/management/remote/mandatory/subjectDelegation/policy11 - test/jdk/javax/management/remote/mandatory/subjectDelegation/policy12 - test/jdk/javax/management/remote/mandatory/subjectDelegation/policy13 - test/jdk/javax/management/remote/mandatory/subjectDelegation/policy14 - test/jdk/javax/management/remote/mandatory/subjectDelegation/policy15 - test/jdk/javax/management/remote/mandatory/subjectDelegation/policy16 - test/jdk/javax/management/remote/mandatory/subjectDelegation/policy21 - test/jdk/javax/management/remote/mandatory/subjectDelegation/policy22 - test/jdk/javax/management/remote/mandatory/subjectDelegation/policy23 - test/jdk/javax/management/remote/mandatory/subjectDelegation/policy24 - test/jdk/javax/management/remote/mandatory/subjectDelegation/policy25 - test/jdk/javax/management/remote/mandatory/subjectDelegation/policy31 - test/jdk/javax/management/remote/mandatory/subjectDelegation/policy32 - test/jdk/javax/management/remote/mandatory/subjectDelegation/policy33 - test/jdk/javax/management/remote/mandatory/subjectDelegation/policy34 - test/jdk/javax/management/remote/mandatory/subjectDelegation/policy35 Changeset: 4276d5c0 Author: Bradford Wetmore Date: 2024-04-04 17:48:41 +0000 URL: https://git.openjdk.org/leyden/commit/4276d5c0048558381c5372ff94db78d956a964d1 8329637: Apparent typo in java.security file property jdk.tls.keyLimits Reviewed-by: ascarpino ! src/java.base/share/conf/security/java.security Changeset: 28216aa9 Author: Viktor Klang Date: 2024-04-04 18:32:59 +0000 URL: https://git.openjdk.org/leyden/commit/28216aa971ea65938117107542152abd532a5384 8328366: Thread.setContextClassloader from thread in FJP commonPool task no longer works after JDK-8327501 Reviewed-by: mchung, alanb ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java ! test/jdk/java/util/concurrent/tck/ForkJoinPool9Test.java Changeset: 83eba863 Author: Vladimir Kozlov Date: 2024-04-04 19:48:48 +0000 URL: https://git.openjdk.org/leyden/commit/83eba863fec5ee7e30c4f9b11122ad1deed3d2ec 8329332: Remove CompiledMethod and CodeBlobLayout classes Reviewed-by: vlivanov, stefank ! src/hotspot/cpu/aarch64/continuationEntry_aarch64.inline.hpp ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/aarch64/frame_aarch64.hpp ! src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/relocInfo_aarch64.cpp ! src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp ! src/hotspot/cpu/arm/frame_arm.cpp ! src/hotspot/cpu/arm/frame_arm.hpp ! src/hotspot/cpu/arm/frame_arm.inline.hpp ! src/hotspot/cpu/ppc/continuationEntry_ppc.inline.hpp ! src/hotspot/cpu/ppc/frame_ppc.cpp ! src/hotspot/cpu/ppc/frame_ppc.inline.hpp ! src/hotspot/cpu/ppc/nativeInst_ppc.cpp ! src/hotspot/cpu/ppc/stackChunkFrameStream_ppc.inline.hpp ! src/hotspot/cpu/riscv/continuationEntry_riscv.inline.hpp ! src/hotspot/cpu/riscv/frame_riscv.cpp ! src/hotspot/cpu/riscv/frame_riscv.hpp ! src/hotspot/cpu/riscv/frame_riscv.inline.hpp ! src/hotspot/cpu/riscv/stackChunkFrameStream_riscv.inline.hpp ! src/hotspot/cpu/s390/frame_s390.cpp ! src/hotspot/cpu/s390/frame_s390.inline.hpp ! src/hotspot/cpu/s390/nativeInst_s390.cpp ! src/hotspot/cpu/s390/nativeInst_s390.hpp ! src/hotspot/cpu/x86/continuationEntry_x86.inline.hpp ! src/hotspot/cpu/x86/frame_x86.cpp ! src/hotspot/cpu/x86/frame_x86.hpp ! src/hotspot/cpu/x86/frame_x86.inline.hpp ! src/hotspot/cpu/x86/stackChunkFrameStream_x86.inline.hpp ! src/hotspot/os/posix/signals_posix.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp ! src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp ! src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp ! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp ! src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp ! src/hotspot/os_cpu/linux_riscv/os_linux_riscv.cpp ! src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp ! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/code/codeBehaviours.cpp ! src/hotspot/share/code/codeBehaviours.hpp ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/code/codeHeapState.hpp ! src/hotspot/share/code/compiledIC.cpp ! src/hotspot/share/code/compiledIC.hpp - src/hotspot/share/code/compiledMethod.cpp - src/hotspot/share/code/compiledMethod.hpp - src/hotspot/share/code/compiledMethod.inline.hpp ! src/hotspot/share/code/debugInfo.cpp ! src/hotspot/share/code/debugInfo.hpp ! src/hotspot/share/code/debugInfoRec.cpp ! src/hotspot/share/code/exceptionHandlerTable.cpp ! src/hotspot/share/code/exceptionHandlerTable.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp + src/hotspot/share/code/nmethod.inline.hpp ! src/hotspot/share/code/pcDesc.cpp ! src/hotspot/share/code/pcDesc.hpp ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/code/relocInfo.hpp ! src/hotspot/share/code/scopeDesc.cpp ! src/hotspot/share/code/scopeDesc.hpp ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/compiler/compilationPolicy.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/oopMap.cpp ! src/hotspot/share/gc/g1/g1HeapRegion.cpp ! src/hotspot/share/gc/shared/gcBehaviours.cpp ! src/hotspot/share/gc/shared/gcBehaviours.hpp ! src/hotspot/share/gc/shared/parallelCleaning.cpp ! src/hotspot/share/gc/shared/parallelCleaning.hpp ! src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp ! src/hotspot/share/gc/x/xUnload.cpp ! src/hotspot/share/gc/z/zUnload.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/oops/method.inline.hpp ! src/hotspot/share/oops/stackChunkOop.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/prims/forte.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/continuation.cpp ! src/hotspot/share/runtime/continuationEntry.cpp ! src/hotspot/share/runtime/continuationEntry.hpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/runtime/continuationHelper.inline.hpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/deoptimization.hpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/frame.hpp ! src/hotspot/share/runtime/frame.inline.hpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/stackChunkFrameStream.inline.hpp ! src/hotspot/share/runtime/vframe.cpp ! src/hotspot/share/runtime/vframe.hpp ! src/hotspot/share/runtime/vframe.inline.hpp ! src/hotspot/share/runtime/vframe_hp.cpp ! src/hotspot/share/runtime/vframe_hp.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CompiledMethod.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfig.java ! test/jdk/com/sun/jdi/EATests.java Changeset: 5c1ad75f Author: Vladimir Kozlov Date: 2024-04-04 17:28:48 +0000 URL: https://git.openjdk.org/leyden/commit/5c1ad75fef0c80460ba4e745dcf3c25a62381795 Merge branch 'master' into premain ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/relocInfo_aarch64.cpp ! src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp ! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/cds/cds_globals.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/code/SCCache.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/code/debugInfoRec.cpp ! src/hotspot/share/code/exceptionHandlerTable.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/code/relocInfo.hpp ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/compiler/compilationPolicy.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compiler_globals.hpp ! src/hotspot/share/compiler/oopMap.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/deoptimization.hpp ! src/hotspot/share/runtime/flags/jvmFlag.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/xmlstream.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/relocInfo_aarch64.cpp ! src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp ! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/cds/cds_globals.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/vmSymbols.hpp + src/hotspot/share/code/SCCache.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/code/debugInfoRec.cpp ! src/hotspot/share/code/exceptionHandlerTable.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/code/relocInfo.hpp ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/compiler/compilationPolicy.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compiler_globals.hpp ! src/hotspot/share/compiler/oopMap.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/deoptimization.hpp ! src/hotspot/share/runtime/flags/jvmFlag.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/xmlstream.cpp From duke at openjdk.org Fri Apr 5 04:41:26 2024 From: duke at openjdk.org (duke) Date: Fri, 5 Apr 2024 04:41:26 GMT Subject: git: openjdk/leyden: premain: 3 new changesets Message-ID: <430731a4-1554-480b-bd79-e0fc153f73f6@openjdk.org> Changeset: b3933d8b Author: iklam Date: 2024-04-02 20:09:38 +0000 URL: https://git.openjdk.org/leyden/commit/b3933d8b417ba9cd74f399174f5cee05827ab598 more clean up of pre-resolution of CP entries ! src/hotspot/share/cds/classPrelinker.cpp ! src/hotspot/share/cds/classPrelinker.hpp ! src/hotspot/share/oops/constantPool.cpp Changeset: b2bc2555 Author: iklam Date: 2024-04-04 19:02:47 +0000 URL: https://git.openjdk.org/leyden/commit/b2bc2555c47c8d3f8f893f37d3793b70776c522e 8329721: Store java.lang.Boolean.{TRUE,FALSE} in CDS archive ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/java.base/share/classes/java/lang/Boolean.java Changeset: 0217a396 Author: iklam Date: 2024-04-04 20:13:37 +0000 URL: https://git.openjdk.org/leyden/commit/0217a39638ed05da9a7fdcfa62d650fa1e1b6f44 8329728: Read arbitrarily long lines in ClassListParser ! src/hotspot/share/cds/classListParser.cpp ! src/hotspot/share/cds/classListParser.hpp + src/hotspot/share/utilities/lineReader.cpp + src/hotspot/share/utilities/lineReader.hpp ! test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassListFormatA.java From duke at openjdk.org Fri Apr 5 14:25:39 2024 From: duke at openjdk.org (duke) Date: Fri, 5 Apr 2024 14:25:39 GMT Subject: git: openjdk/leyden: premain: Minor fixes to WarmupMakefile Message-ID: <17a24bf6-f0e1-4b41-9220-104cbecc0826@openjdk.org> Changeset: aa6d5444 Author: Ashutosh Mehra Date: 2024-04-05 10:23:51 +0000 URL: https://git.openjdk.org/leyden/commit/aa6d5444f77d3ea184aa5e4cb98893681441dc53 Minor fixes to WarmupMakefile Signed-off-by: Ashutosh Mehra ! test/hotspot/jtreg/premain/spring-petclinic/WarmupMakefile From duke at openjdk.org Fri Apr 5 17:11:47 2024 From: duke at openjdk.org (duke) Date: Fri, 5 Apr 2024 17:11:47 GMT Subject: git: openjdk/leyden: premain: Cleanup remove_unshareable_info() and restore_unshareable_info() Message-ID: Changeset: 7ecd661f Author: Igor Veresov Date: 2024-04-05 10:09:24 +0000 URL: https://git.openjdk.org/leyden/commit/7ecd661feaba21439f1b70822b65c2c930cf46da Cleanup remove_unshareable_info() and restore_unshareable_info() recursion ! src/hotspot/share/oops/trainingData.cpp ! src/hotspot/share/oops/trainingData.hpp From duke at openjdk.org Mon Apr 8 04:06:22 2024 From: duke at openjdk.org (duke) Date: Mon, 8 Apr 2024 04:06:22 GMT Subject: git: openjdk/leyden: premain: (1) enable ArchiveLoaderLookupCache, by default when PreloadSharedClasses is enabled; (2) do not disable Inline for new workflow Message-ID: <5d9c7884-2a6d-48ec-b2e7-b1812ce2e5ea@openjdk.org> Changeset: 908503f1 Author: iklam Date: 2024-04-07 21:05:56 +0000 URL: https://git.openjdk.org/leyden/commit/908503f1a1cc1ec931ff6ff5de0331c55748540f (1) enable ArchiveLoaderLookupCache, by default when PreloadSharedClasses is enabled; (2) do not disable Inline for new workflow ! src/hotspot/share/cds/cdsConfig.cpp ! test/hotspot/jtreg/premain/spring-petclinic/Makefile From duke at openjdk.org Mon Apr 8 16:30:50 2024 From: duke at openjdk.org (duke) Date: Mon, 8 Apr 2024 16:30:50 GMT Subject: git: openjdk/leyden: premain: Add targets to run warmup test using new single-step workflow Message-ID: <926d2783-a1bf-4792-9bc0-f04adf179e66@openjdk.org> Changeset: 057360f9 Author: Ashutosh Mehra Date: 2024-04-08 12:28:23 +0000 URL: https://git.openjdk.org/leyden/commit/057360f9e778ce153ab49509056bc6c01ca03122 Add targets to run warmup test using new single-step workflow Signed-off-by: Ashutosh Mehra ! test/hotspot/jtreg/premain/spring-petclinic/WarmupMakefile From duke at openjdk.org Wed Apr 10 04:17:04 2024 From: duke at openjdk.org (duke) Date: Wed, 10 Apr 2024 04:17:04 GMT Subject: git: openjdk/leyden: premain: 2 new changesets Message-ID: <8411ab5f-87d7-427c-8eab-5bb573bd1af2@openjdk.org> Changeset: 338719d4 Author: iklam Date: 2024-04-09 16:13:26 +0000 URL: https://git.openjdk.org/leyden/commit/338719d49fad5420cf72cd4a01fcab1728990469 Refactoring: moved class init code into cds/classPreinitializer.cpp + src/hotspot/share/cds/classPreinitializer.cpp + src/hotspot/share/cds/classPreinitializer.hpp ! src/hotspot/share/cds/classPrelinker.cpp ! src/hotspot/share/cds/classPrelinker.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp Changeset: f546e292 Author: iklam Date: 2024-04-09 21:15:05 +0000 URL: https://git.openjdk.org/leyden/commit/f546e292741eb534e99d6f06292d0696261576a2 More refactoring: move code related to pre-initialization to classPreinitializer.cpp ! src/hotspot/share/cds/classPreinitializer.cpp ! src/hotspot/share/cds/classPreinitializer.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp From duke at openjdk.org Thu Apr 11 21:55:57 2024 From: duke at openjdk.org (duke) Date: Thu, 11 Apr 2024 21:55:57 GMT Subject: git: openjdk/leyden: premain: 2 new changesets Message-ID: <6bc4da56-f7d2-4b4b-94bf-d51df473e2d8@openjdk.org> Changeset: fdcc1180 Author: iklam Date: 2024-04-10 15:04:45 +0000 URL: https://git.openjdk.org/leyden/commit/fdcc1180f63f9838e2f77a274ac6ee3ea34e0670 Refactor: move is_vm_class() into ClassPreloader; fixed inconsistent use of xxx_klass vs _xxx_class in ClassPreloader/ClassPrelinker ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/classPrelinker.cpp ! src/hotspot/share/cds/classPrelinker.hpp ! src/hotspot/share/cds/classPreloader.cpp ! src/hotspot/share/cds/classPreloader.hpp ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/metaspaceShared.cpp Changeset: e211d5d7 Author: iklam Date: 2024-04-10 20:44:25 +0000 URL: https://git.openjdk.org/leyden/commit/e211d5d7f417fbe2a7bca817caa00a6f15ad6c8c Moved the management of the "receipes" to the FinalImageRecipes class ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/classPreinitializer.hpp ! src/hotspot/share/cds/classPrelinker.cpp ! src/hotspot/share/cds/classPrelinker.hpp ! src/hotspot/share/cds/classPreloader.hpp + src/hotspot/share/cds/finalImageRecipes.cpp + src/hotspot/share/cds/finalImageRecipes.hpp ! src/hotspot/share/cds/metaspaceShared.cpp From davidalayachew at gmail.com Thu Apr 11 22:37:10 2024 From: davidalayachew at gmail.com (David Alayachew) Date: Thu, 11 Apr 2024 18:37:10 -0400 Subject: What are Leyden's plans to minimize application footprint, specifically disk footprint? Message-ID: Hello, I don't know where this belongs, so please redirect this as needed. I am working on building an executable for my Microsoft Paint clone, and I used jpackage to do it. My module-info.java only had java.base and java.desktop, but the generated binary (after running the installer) was ~71MB. Thanks to a helpful answer on Stackoverflow ( https://stackoverflow.com/questions/78308134), I was able to bring that down to ~49MB using --jlink-options --compress=zip-9. I was grateful for that. But a double digit sized executable generated from <3000 lines of Swing code with no resources was a bit difficult to swallow. Obviously, those 3000 lines house a lot behind the curtain. * There's the 2 modules -- java.base and java.desktop. Unfortunately, they also happen to be the 2 biggest modules in the entirety of the JDK. Sometimes, I wonder "Why are they that large? Could they have been broken down further? Might that happen in the future?" * There's also the Operating System specific files. I see 1MB dedicated to just awt.dll, for example. I am Windows 11. * And then there's the jvm itself, which is a whole 12 MB on my machine. It seems to also be a dll. All of this is what is created when I run the installer. So it all makes sense, and I don't think any of these components are being needlessly included. But I still want to know -- what are Leyden's plans to minimize application footprint, specifically disk footprint? Thank you for your time! David Alayachew -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Apr 12 05:19:58 2024 From: duke at openjdk.org (duke) Date: Fri, 12 Apr 2024 05:19:58 GMT Subject: git: openjdk/leyden: premain: Added build/test scripts for new demo: https://helidon.io/docs/v4/se/guides/quickstart Message-ID: <871ff6c2-0427-44e4-b890-26e150145011@openjdk.org> Changeset: 194ae8ad Author: iklam Date: 2024-04-11 22:19:11 +0000 URL: https://git.openjdk.org/leyden/commit/194ae8add393083c9b618e818efc5677cc271551 Added build/test scripts for new demo: https://helidon.io/docs/v4/se/guides/quickstart + test/hotspot/jtreg/premain/helidon-quickstart-se/.gitignore + test/hotspot/jtreg/premain/helidon-quickstart-se/Main.java.diff + test/hotspot/jtreg/premain/helidon-quickstart-se/Makefile + test/hotspot/jtreg/premain/spring-petclinic/.gitignore + test/hotspot/jtreg/runtime/cds/appcds/applications/HelidonQuickStartSE.java From Alan.Bateman at oracle.com Fri Apr 12 09:06:39 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Apr 2024 10:06:39 +0100 Subject: What are Leyden's plans to minimize application footprint, specifically disk footprint? In-Reply-To: References: Message-ID: <3c513661-d65a-4588-a83a-526b69f56d74@oracle.com> On 11/04/2024 23:37, David Alayachew wrote: > : > > * There's the 2 modules -- java.base and java.desktop. Unfortunately, > they also happen to be the 2 biggest modules in the entirety of the > JDK. Sometimes, I wonder "Why are they that large? Could they have > been broken down further? Might that happen in the future?" > The SO post that you linked to doesn't mention --strip-debug which will strip the debug attributes from the class files. That should reduce the size by another few MBs but at the cost of less useful stack traces. There are at least 5 modules if you have included java.desktop. Look at the? "release" file in the top-level directory of the generated run-time image to see full set. You'll see java.xml in the set, another large module, because there are APIs in java.desktop (particularly in image I/O) that have XML types in method signatures. Almost all exploration in the past into splitting the APIs for AWT/Swing/Image/Sound/etc. into cohesive modules came to nothing because of all the cross references between these APIs. The exception is the java.awt.datatransfer module which provides something cohesive in non-UI contexts, e.g. XML binding and web services APIs. One thing that isn't there is a jlink plugin for limiting java.desktop to "headless mode", interesting for server environments that do things like process images and thus use APIs from the java.desktop module. So right now, I'm not aware of any effort to re-visit the java.desktop module. Efforts have tended to focus more on compression and reducing the size of existing bits. Maybe in the future that closed work assumptions could help but right now the API surface (and resulting implementation) is huge. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Fri Apr 12 11:52:00 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Apr 2024 13:52:00 +0200 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> Message-ID: On 2024-04-02 21:16, Jiangli Zhou wrote: > Hi?Magnus, > > In today's zoom meeting with Alan, Ron, Liam and Chuck, we (briefly) > discussed how to move forward contributing the static Java related > changes (additional runtime fixes/enhancements?on top of the existing > static support in JDK) from > https://github.com/openjdk/leyden/tree/hermetic-java-runtime to JDK > mainline. > > Just a bit more details/context below, which may be useful for others > reading this thread. > > The https://github.com/openjdk/leyden/tree/hermetic-java-runtime > branch currently contains following for supporting hermetic Java > (without the launcher work for runtime support): > > 1. Build change for linking the Java launcher (as bin/javastatic) with > JDK/hotspot static libraries (.a), mainly in > https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk. > The part for creating the complete sets of static libraries (including > libjvm.a) has already been included in the mainline since last year. > https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk > is in a very raw state and is intended to demonstrate the capability > of building a static Java launcher. Indeed. It is nowhere near being able to be integrated. > > 2. Additional runtime fixes/enhancements?on top of the existing static > support in JDK, e.g. support further lookup dynamic native library if > the built-in native library cannot be found. > > 3. Some initial (prototype) work on supporting hermetic JDK resource > files in the jimage (JDK modules image). > > To move forward, one of the earliest items needed is to add the > capability of building the fully statically linked Java launcher in > JDK mainline. The other static Java runtime changes can be followed up > after the launcher linking part, so they can be built and tested as > individual PRs created for the JDK mainline. Magnus, you have > expressed interest in helping get the launcher linking part (refactor > from > https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk) > into JDK mainline. What's your thought on prioritizing the launcher > static linking part before other makefile clean ups for static libraries? Trust me, my absolute top priority now is working on getting the proper build support needed for Hermetic Java. I can't prioritize it any higher. I am not sure what you are asking for. We can't just merge StaticLink.gmk from your prototype. And even if we did, what good will it do you? The problem you are running into is that the build system has not been designed to properly support static linking. There are already 3-4 hacks in place to get something sort-of useful out, but they are prone to breaking. I assume that we agree that for Hermetic Java to become a success, we need to have a stable foundation for static builds. The core problem of all static linking hacks is that they are not integrated in the right place. They need to be a core part of what NativeCompilation delivers, not something done in a separate file. To put it in other words, StaticLink.gmk from your branch do not need cleanup -- it needs to go away, and the functionality moved to the proper place. My approach is that NativeCompilation should support doing either only dynamic linking (as today), or static linking (as today with STATIC_LIBS or STATIC_BUILD), or both. The assumption is that the latter will be default, or at least should be tested by default in GHA. For this to work, we need to compile the source code to .o files only once, and then link these .o files either into a dynamic or a static library (or both). This, in turn, require several changes: 1) The linking code needs to be cleaned up, and all technical debt needs to be resolved. This is what I have been doing since I started working on static builds for Hermetic Java. JDK-8329704 (which was integrated yesterday) was the first major milestone of this cleanup. Now, the path were to find a library created by the JDK (static or dynamic) is encapsulated in ResolveLibPath. This is currently a monster, but at least all knowledge is collected in a single location, instead of spread over the code base. Getting this simplified is the next step. 2) We need to stop passing the STATIC_BUILD define when compiling. This is partially addressed in your PR, where you have replaced #ifdef STATIC_BUILD with a dynamic lookup. But there is also the problem of JNI/JVMTI entry points. I have been pondering how we can compile the code in a way so we support both dynamic and static name resolution, and I think I have a solution. This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. /Magnus > > Thanks! > Jiangli > > On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou > wrote: > > On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou > wrote: > > > > Hi Magnus, > > > > Thanks for looking into this from the build perspective. > > > > On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie > > wrote: > > > > > > 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. > > > > Some additional hermetic Java related references that are also > useful: > > > > - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug > that > > links to the issues for resolving static linking issues so far > > - https://github.com/openjdk/jdk21/pull/26 is the enhancement for > > building the complete set of static libraries in JDK/VM, > particularly > > including libjvm.a > > > > > > > > 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? > > > > I have a similar view as Alan responded in your other email thread. > > Things are still in the early stage for the general solution. > > > > In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime > > branch, when configuring JDK with --with-static-java=yes, the JDK > > binary contains the following extra artifacts: > > > > - static-libs/*.a: The complete set of JDK/VM static libraries > > - jdk/bin/javastatic: A demo Java launcher fully statically linked > > with the selected JDK .a libraries (e.g. it currently statically > link > > with the headless) and libjvm.a. It's the standard Java launcher > > without additional work for hermetic Java. > > > > In our prototype for hermetic Java, we build the hermetic executable > > image (a single image) from the following input (see description on > > singlejar packaging tool in > > https://cr.openjdk.org/~jiangli/hermetic_java.pdf): > > > > - A customized launcher (with additional work for hermetic) > executable > > fully statically linked with JDK/VM static libraries (.a files), > > application natives and dependencies (e.g. in .a static libraries) > > - JDK lib/modules, JDK resource files > > - Application classes and resource files > > > > Including a JDK library .a into the corresponding .jmod would > require > > extracting the .a for linking with the executable. In some systems > > that may cause memory overhead due to the extracted copy of the .a > > files. I think we should consider the memory overhead issue. > > > > One possibility (as Alan described in his response) is for jlink to > > invoke the ld on the build system. jlink could pass the needed JDK > > static libraries and libjvm.a (provided as part of the JDK > binary) to > > ld based on the modules required for the application. > > > > I gave a bit more thoughts on this one. For jlink to trigger ld, it > would need to know the complete linker options and inputs. Those > include options and inputs related to the application part as well. In > some usages, it might be easier to handle native linking separately > and pass the linker output, the executable to jlink directly. Maybe we > could consider supporting different modes for various usages > requirements, from static libraries and native linking point of view: > > Mode #1 > Support .jmod packaged natives static libraries, for both JDK/VM .a > and application natives and dependencies. If the inputs to jlink > include .jmods, jlink can extract the .a libraries and pass the > information to ld to link the executable. > > Mode #2 > Support separate .a as jlink input. Jlink could pass the path > information to the .a libraries and other linker options to ld to > create the executable. > > For both mode #1 and #2, jlink would then use the linker output > executable to create the final hermetic image. > > Mode #3 > Support a fully linked executable as a jlink input. When a linked > executable is given to jlink, it can process it directly with other > JDK data/files to create the final image, without native linking step. > > Any other thoughts and considerations? > > Best, > Jiangli > > > > > > > 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. > > > > An alternative with less memory overhead could be using application > > modular JAR and separate .a as the input for jlink. > > > > > 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. > > > > Part of the current effort includes resolving the discovered symbol > > collision issues with static linking. Will respond to your other > email > > on the symbol issue separately later. > > > > > > > > 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. > > > > I think we would need both configure flag and special target for the > > static builds. > > > > > 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. > > > > For the potential objcopy work to resolve symbol issues, we can add > > that conditionally in NativeCompilation.gmk if STATIC_LIBS is > true. We > > have an internal prototype (not included in > > https://github.com/openjdk/leyden/tree/hermetic-java-runtime > yet) done > > by one of colleagues for localizing symbols in libfreetype using > > objcopy. > > > > > > > > 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". > > > > If we want to also build a fully statically linked launcher, maybe > > --with-static-java? Being able to configure either dynamic, > static or > > both as you suggested also seems to be a good idea. > > > > > 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. > > > > Completely agree. It would be good to avoid recompiling the .o file > > for static and dynamic builds. As proposed in > > https://bugs.openjdk.org/browse/JDK-8303796: > > > > It's beneficial to be able to build both .so and .a from the > same set > > of .o files. That would involve some changes to handle the > dynamic JDK > > and static JDK difference at runtime, instead of relying on the > > STATIC_BUILD macro. > > > > > > > > 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. > > > > Renaming or redefining the symbol at build time could cause > confusions > > with debugging. That's a concern raised in > > https://github.com/openjdk/jdk/pull/17456 discussions. > > > > Additionally, redefining symbols using tools like objcopy may not > > handle member names referenced in string literals. For example, in > > https://github.com/openjdk/jdk/pull/17456 additional changes are > > needed in assembling and SA to reflect the symbol change. > > > > > > > > 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? > > > > We have done some testing with jtreg SA related tests for the fully > > statically linked `javastatic`. > > > > If we use objcopy to localize symbols in hotspot, it's not yet clear > > what's the impact on SA. We could do some tests. The other question > > that I raised is the supported gcc versions (for partial linking) > > related to the solution. > > > > Best, > > Jiangli > > > > > > > > /Magnus > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Sun Apr 14 04:19:30 2024 From: davidalayachew at gmail.com (David Alayachew) Date: Sun, 14 Apr 2024 00:19:30 -0400 Subject: What are Leyden's plans to minimize application footprint, specifically disk footprint? In-Reply-To: <3c513661-d65a-4588-a83a-526b69f56d74@oracle.com> References: <3c513661-d65a-4588-a83a-526b69f56d74@oracle.com> Message-ID: Thank you very much for the response Alan! I spoke to the answerer on SO, and got all of this info added. Very much appreciated! Do you have any thoughts on the main question I asked? Java is doing amazing work to make programs faster and safer. Ultimately, my main question is to see if anything is being done to also minimize disk size of its generated binaries. On Fri, Apr 12, 2024 at 5:07?AM Alan Bateman wrote: > On 11/04/2024 23:37, David Alayachew wrote: > > : > > * There's the 2 modules -- java.base and java.desktop. Unfortunately, they > also happen to be the 2 biggest modules in the entirety of the JDK. > Sometimes, I wonder "Why are they that large? Could they have been broken > down further? Might that happen in the future?" > > > The SO post that you linked to doesn't mention --strip-debug which will > strip the debug attributes from the class files. That should reduce the > size by another few MBs but at the cost of less useful stack traces. > > There are at least 5 modules if you have included java.desktop. Look at > the "release" file in the top-level directory of the generated run-time > image to see full set. You'll see java.xml in the set, another large > module, because there are APIs in java.desktop (particularly in image I/O) > that have XML types in method signatures. > > Almost all exploration in the past into splitting the APIs for > AWT/Swing/Image/Sound/etc. into cohesive modules came to nothing because of > all the cross references between these APIs. The exception is the > java.awt.datatransfer module which provides something cohesive in non-UI > contexts, e.g. XML binding and web services APIs. One thing that isn't > there is a jlink plugin for limiting java.desktop to "headless mode", > interesting for server environments that do things like process images and > thus use APIs from the java.desktop module. > > So right now, I'm not aware of any effort to re-visit the java.desktop > module. Efforts have tended to focus more on compression and reducing the > size of existing bits. Maybe in the future that closed work assumptions > could help but right now the API surface (and resulting implementation) is > huge. > > -Alan > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jianglizhou at google.com Tue Apr 16 01:01:53 2024 From: jianglizhou at google.com (Jiangli Zhou) Date: Mon, 15 Apr 2024 18:01:53 -0700 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> Message-ID: Magnus, thanks for the response. Please see comments inlined below. On Fri, Apr 12, 2024 at 4:52?AM Magnus Ihse Bursie wrote: > > On 2024-04-02 21:16, Jiangli Zhou wrote: > > Hi Magnus, > > In today's zoom meeting with Alan, Ron, Liam and Chuck, we (briefly) discussed how to move forward contributing the static Java related changes (additional runtime fixes/enhancements on top of the existing static support in JDK) from https://github.com/openjdk/leyden/tree/hermetic-java-runtime to JDK mainline. > > Just a bit more details/context below, which may be useful for others reading this thread. > > The https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch currently contains following for supporting hermetic Java (without the launcher work for runtime support): > > 1. Build change for linking the Java launcher (as bin/javastatic) with JDK/hotspot static libraries (.a), mainly in https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk. The part for creating the complete sets of static libraries (including libjvm.a) has already been included in the mainline since last year. https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk is in a very raw state and is intended to demonstrate the capability of building a static Java launcher. > > Indeed. It is nowhere near being able to be integrated. > The main purpose of StaticLink.gmk is to support the static-java-image make target, which can be used to perform the actual static linking step using libjvm.a and JDK static libraries. That currently doesn't exist in the JDK mainline. Creating a "fully" statically linked Java launcher is the first step (out of many) towards supporting static/hermetic Java. As part of cleaning/refactoring/integrating for the static linking step, we want to agree and decide/accept on the following: - Support the "fully" statically linked java launcher for testing and demoing the capability of static JDK support, e.g. - Support running jtreg testing using the "fully" statically linked Java launcher - Set up tests in github workflow to help detect any breaking changes for static support, e.g. new symbol issues introduced by any changes. There were some earlier discussions on this with Ron and Alan during the zoom meetings. - Which JDK native libraries to be statically linked with the new launcher target? E.g. StaticLink.gmk currently excludes libjsound.a, libawt_xawt.a, etc from statically linked with the launcher. - Do we want more than one statically linked launcher target, based on the set of linked native libraries? Based on the decisions of the above, the launcher static linking part would mostly be in a different shape when it's integrated into the mainline. That's why I referred to StaticLink.gmk as in a "very raw" state. Here is a high-level view of the state of things for static support: (I) What we already have in the JDK mainline: - Able to build a complete set of JDK/VM static libraries using `static-libs-image` make target (necessary for supporting static JDK) - Compilation for .o files are done separately for the static libraries and dynamic library (ok for now) (II) What missing: - Static linking step as mentioned above (III) What needs to be improved (require cleanups and refactoring, and you mentioned some of those in your response as well): - Support building both the static libraries and dynamic libraries using the same set of .o files, instead of separately compiled .o files. That helps improve build speed and reduce memory overhead for building JDK. Your current refactoring work aims to help that. - Clean up the usages of STATIC_BUILD macro. Most of the usages are in test code. - Other runtime fixes/enhancements in the leyden https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch I think most work mentioned in III has dependencies on II. We need a workable base to be able to build the "fully" statically linked launcher for building and testing the work mentioned in III, when integrating any of those to the JDK mainline. The makefile refactoring work can be done in parallel but does not need to be completed before we add the static linking step in JDK mainline. > > 2. Additional runtime fixes/enhancements on top of the existing static support in JDK, e.g. support further lookup dynamic native library if the built-in native library cannot be found. > > 3. Some initial (prototype) work on supporting hermetic JDK resource files in the jimage (JDK modules image). > > To move forward, one of the earliest items needed is to add the capability of building the fully statically linked Java launcher in JDK mainline. The other static Java runtime changes can be followed up after the launcher linking part, so they can be built and tested as individual PRs created for the JDK mainline. Magnus, you have expressed interest in helping get the launcher linking part (refactor from https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk) into JDK mainline. What's your thought on prioritizing the launcher static linking part before other makefile clean ups for static libraries? > > Trust me, my absolute top priority now is working on getting the proper build support needed for Hermetic Java. I can't prioritize it any higher. Thanks! > > I am not sure what you are asking for. We can't just merge StaticLink.gmk from your prototype. And even if we did, what good will it do you? Please see my comments above. > > The problem you are running into is that the build system has not been designed to properly support static linking. There are already 3-4 hacks in place to get something sort-of useful out, but they are prone to breaking. I assume that we agree that for Hermetic Java to become a success, we need to have a stable foundation for static builds. > > The core problem of all static linking hacks is that they are not integrated in the right place. They need to be a core part of what NativeCompilation delivers, not something done in a separate file. To put it in other words, StaticLink.gmk from your branch do not need cleanup -- it needs to go away, and the functionality moved to the proper place. > > My approach is that NativeCompilation should support doing either only dynamic linking (as today), or static linking (as today with STATIC_LIBS or STATIC_BUILD), or both. The assumption is that the latter will be default, or at least should be tested by default in GHA. For this to work, we need to compile the source code to .o files only once, and then link these .o files either into a dynamic or a static library (or both). As of today, the leyden https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch can build a "fully" statically linked Java launcher. The issue of compiling the dynamic and static libraries .o files separately is not a blocker. It's good to have it resolved at some point of time. > > This, in turn, require several changes: > > 1) The linking code needs to be cleaned up, and all technical debt needs to be resolved. This is what I have been doing since I started working on static builds for Hermetic Java. JDK-8329704 (which was integrated yesterday) was the first major milestone of this cleanup. Now, the path were to find a library created by the JDK (static or dynamic) is encapsulated in ResolveLibPath. This is currently a monster, but at least all knowledge is collected in a single location, instead of spread over the code base. Getting this simplified is the next step. > > 2) We need to stop passing the STATIC_BUILD define when compiling. This is partially addressed in your PR, where you have replaced #ifdef STATIC_BUILD with a dynamic lookup. But there is also the problem of JNI/JVMTI entry points. I have been pondering how we can compile the code in a way so we support both dynamic and static name resolution, and I think I have a solution. > > This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. Thumbs up! That seems to be a good direction. Currently in the leyden branch, it first looks up the unique JNI_OnLoad<_lib_name>|Agent_OnLoad<_lib_name> etc for built-in libraries, then search for the dynamic libraries using the conventional naming when necessary. e.g.: https://github.com/openjdk/leyden/commit/a5c886d2e85a0ff0c3712a5488ae61d8c9d7ba1a https://github.com/openjdk/leyden/commit/1da8e3240e0bd27366d19f2e7dde386e46015135 When spec supports JNI_OnLoad_ and etc. for dynamic libraries, we may still need to support the conventional naming without the <_lib_name> part for existing libraries out there. > > And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. > > A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. Thank you for taking this on! Potentially we could consider taking the objcopy to localizing hotspot symbols on unix-like platforms, based on https://github.com/openjdk/jdk/pull/17456 discussions. Additional testing is still needed to verify the solution. > > My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. Most of the JDK resources are now supported as hermetic jimage (lib/modules) bundled in the https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch. The remaining sound.properties, ct.sym and .jfc files can be handled later. Overally, that part of the work has confirmed the hermetic jimage bundled solution is robust and helps resolve some of the difficult start-up sequence issues observed when the hermetic resource was implemented using JAR file based solution. It might be a good idea to follow up on the static linking discussion in tomorrow's zoom meeting (hope you'll be able to join tomorrow). Thanks! Jiangli > > /Magnus > > > > Thanks! > Jiangli > > On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: >> >> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: >> > >> > Hi Magnus, >> > >> > Thanks for looking into this from the build perspective. >> > >> > On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie >> > wrote: >> > > >> > > 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. >> > >> > Some additional hermetic Java related references that are also useful: >> > >> > - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that >> > links to the issues for resolving static linking issues so far >> > - https://github.com/openjdk/jdk21/pull/26 is the enhancement for >> > building the complete set of static libraries in JDK/VM, particularly >> > including libjvm.a >> > >> > > >> > > 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? >> > >> > I have a similar view as Alan responded in your other email thread. >> > Things are still in the early stage for the general solution. >> > >> > In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime >> > branch, when configuring JDK with --with-static-java=yes, the JDK >> > binary contains the following extra artifacts: >> > >> > - static-libs/*.a: The complete set of JDK/VM static libraries >> > - jdk/bin/javastatic: A demo Java launcher fully statically linked >> > with the selected JDK .a libraries (e.g. it currently statically link >> > with the headless) and libjvm.a. It's the standard Java launcher >> > without additional work for hermetic Java. >> > >> > In our prototype for hermetic Java, we build the hermetic executable >> > image (a single image) from the following input (see description on >> > singlejar packaging tool in >> > https://cr.openjdk.org/~jiangli/hermetic_java.pdf): >> > >> > - A customized launcher (with additional work for hermetic) executable >> > fully statically linked with JDK/VM static libraries (.a files), >> > application natives and dependencies (e.g. in .a static libraries) >> > - JDK lib/modules, JDK resource files >> > - Application classes and resource files >> > >> > Including a JDK library .a into the corresponding .jmod would require >> > extracting the .a for linking with the executable. In some systems >> > that may cause memory overhead due to the extracted copy of the .a >> > files. I think we should consider the memory overhead issue. >> > >> > One possibility (as Alan described in his response) is for jlink to >> > invoke the ld on the build system. jlink could pass the needed JDK >> > static libraries and libjvm.a (provided as part of the JDK binary) to >> > ld based on the modules required for the application. >> > >> >> I gave a bit more thoughts on this one. For jlink to trigger ld, it >> would need to know the complete linker options and inputs. Those >> include options and inputs related to the application part as well. In >> some usages, it might be easier to handle native linking separately >> and pass the linker output, the executable to jlink directly. Maybe we >> could consider supporting different modes for various usages >> requirements, from static libraries and native linking point of view: >> >> Mode #1 >> Support .jmod packaged natives static libraries, for both JDK/VM .a >> and application natives and dependencies. If the inputs to jlink >> include .jmods, jlink can extract the .a libraries and pass the >> information to ld to link the executable. >> >> Mode #2 >> Support separate .a as jlink input. Jlink could pass the path >> information to the .a libraries and other linker options to ld to >> create the executable. >> >> For both mode #1 and #2, jlink would then use the linker output >> executable to create the final hermetic image. >> >> Mode #3 >> Support a fully linked executable as a jlink input. When a linked >> executable is given to jlink, it can process it directly with other >> JDK data/files to create the final image, without native linking step. >> >> Any other thoughts and considerations? >> >> Best, >> Jiangli >> >> > > >> > > 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. >> > >> > An alternative with less memory overhead could be using application >> > modular JAR and separate .a as the input for jlink. >> > >> > > 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. >> > >> > Part of the current effort includes resolving the discovered symbol >> > collision issues with static linking. Will respond to your other email >> > on the symbol issue separately later. >> > >> > > >> > > 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. >> > >> > I think we would need both configure flag and special target for the >> > static builds. >> > >> > > 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. >> > >> > For the potential objcopy work to resolve symbol issues, we can add >> > that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We >> > have an internal prototype (not included in >> > https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done >> > by one of colleagues for localizing symbols in libfreetype using >> > objcopy. >> > >> > > >> > > 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". >> > >> > If we want to also build a fully statically linked launcher, maybe >> > --with-static-java? Being able to configure either dynamic, static or >> > both as you suggested also seems to be a good idea. >> > >> > > 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. >> > >> > Completely agree. It would be good to avoid recompiling the .o file >> > for static and dynamic builds. As proposed in >> > https://bugs.openjdk.org/browse/JDK-8303796: >> > >> > It's beneficial to be able to build both .so and .a from the same set >> > of .o files. That would involve some changes to handle the dynamic JDK >> > and static JDK difference at runtime, instead of relying on the >> > STATIC_BUILD macro. >> > >> > > >> > > 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. >> > >> > Renaming or redefining the symbol at build time could cause confusions >> > with debugging. That's a concern raised in >> > https://github.com/openjdk/jdk/pull/17456 discussions. >> > >> > Additionally, redefining symbols using tools like objcopy may not >> > handle member names referenced in string literals. For example, in >> > https://github.com/openjdk/jdk/pull/17456 additional changes are >> > needed in assembling and SA to reflect the symbol change. >> > >> > > >> > > 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? >> > >> > We have done some testing with jtreg SA related tests for the fully >> > statically linked `javastatic`. >> > >> > If we use objcopy to localize symbols in hotspot, it's not yet clear >> > what's the impact on SA. We could do some tests. The other question >> > that I raised is the supported gcc versions (for partial linking) >> > related to the solution. >> > >> > Best, >> > Jiangli >> > >> > > >> > > /Magnus >> > > From tanksherman27 at gmail.com Tue Apr 16 05:23:55 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Tue, 16 Apr 2024 13:23:55 +0800 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> Message-ID: > And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. objcopy is also available on Windows, if the question about alternative tooling is still unanswered :) best regards, Julian On Fri, Apr 12, 2024 at 7:52?PM Magnus Ihse Bursie wrote: > > On 2024-04-02 21:16, Jiangli Zhou wrote: > > Hi Magnus, > > In today's zoom meeting with Alan, Ron, Liam and Chuck, we (briefly) discussed how to move forward contributing the static Java related changes (additional runtime fixes/enhancements on top of the existing static support in JDK) from https://github.com/openjdk/leyden/tree/hermetic-java-runtime to JDK mainline. > > Just a bit more details/context below, which may be useful for others reading this thread. > > The https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch currently contains following for supporting hermetic Java (without the launcher work for runtime support): > > 1. Build change for linking the Java launcher (as bin/javastatic) with JDK/hotspot static libraries (.a), mainly in https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk. The part for creating the complete sets of static libraries (including libjvm.a) has already been included in the mainline since last year. https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk is in a very raw state and is intended to demonstrate the capability of building a static Java launcher. > > Indeed. It is nowhere near being able to be integrated. > > > 2. Additional runtime fixes/enhancements on top of the existing static support in JDK, e.g. support further lookup dynamic native library if the built-in native library cannot be found. > > 3. Some initial (prototype) work on supporting hermetic JDK resource files in the jimage (JDK modules image). > > To move forward, one of the earliest items needed is to add the capability of building the fully statically linked Java launcher in JDK mainline. The other static Java runtime changes can be followed up after the launcher linking part, so they can be built and tested as individual PRs created for the JDK mainline. Magnus, you have expressed interest in helping get the launcher linking part (refactor from https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk) into JDK mainline. What's your thought on prioritizing the launcher static linking part before other makefile clean ups for static libraries? > > Trust me, my absolute top priority now is working on getting the proper build support needed for Hermetic Java. I can't prioritize it any higher. > > I am not sure what you are asking for. We can't just merge StaticLink.gmk from your prototype. And even if we did, what good will it do you? > > The problem you are running into is that the build system has not been designed to properly support static linking. There are already 3-4 hacks in place to get something sort-of useful out, but they are prone to breaking. I assume that we agree that for Hermetic Java to become a success, we need to have a stable foundation for static builds. > > The core problem of all static linking hacks is that they are not integrated in the right place. They need to be a core part of what NativeCompilation delivers, not something done in a separate file. To put it in other words, StaticLink.gmk from your branch do not need cleanup -- it needs to go away, and the functionality moved to the proper place. > > My approach is that NativeCompilation should support doing either only dynamic linking (as today), or static linking (as today with STATIC_LIBS or STATIC_BUILD), or both. The assumption is that the latter will be default, or at least should be tested by default in GHA. For this to work, we need to compile the source code to .o files only once, and then link these .o files either into a dynamic or a static library (or both). > > This, in turn, require several changes: > > 1) The linking code needs to be cleaned up, and all technical debt needs to be resolved. This is what I have been doing since I started working on static builds for Hermetic Java. JDK-8329704 (which was integrated yesterday) was the first major milestone of this cleanup. Now, the path were to find a library created by the JDK (static or dynamic) is encapsulated in ResolveLibPath. This is currently a monster, but at least all knowledge is collected in a single location, instead of spread over the code base. Getting this simplified is the next step. > > 2) We need to stop passing the STATIC_BUILD define when compiling. This is partially addressed in your PR, where you have replaced #ifdef STATIC_BUILD with a dynamic lookup. But there is also the problem of JNI/JVMTI entry points. I have been pondering how we can compile the code in a way so we support both dynamic and static name resolution, and I think I have a solution. > > This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. > > And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. > > A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. > > My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. > > /Magnus > > > > Thanks! > Jiangli > > On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: >> >> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: >> > >> > Hi Magnus, >> > >> > Thanks for looking into this from the build perspective. >> > >> > On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie >> > wrote: >> > > >> > > 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. >> > >> > Some additional hermetic Java related references that are also useful: >> > >> > - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that >> > links to the issues for resolving static linking issues so far >> > - https://github.com/openjdk/jdk21/pull/26 is the enhancement for >> > building the complete set of static libraries in JDK/VM, particularly >> > including libjvm.a >> > >> > > >> > > 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? >> > >> > I have a similar view as Alan responded in your other email thread. >> > Things are still in the early stage for the general solution. >> > >> > In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime >> > branch, when configuring JDK with --with-static-java=yes, the JDK >> > binary contains the following extra artifacts: >> > >> > - static-libs/*.a: The complete set of JDK/VM static libraries >> > - jdk/bin/javastatic: A demo Java launcher fully statically linked >> > with the selected JDK .a libraries (e.g. it currently statically link >> > with the headless) and libjvm.a. It's the standard Java launcher >> > without additional work for hermetic Java. >> > >> > In our prototype for hermetic Java, we build the hermetic executable >> > image (a single image) from the following input (see description on >> > singlejar packaging tool in >> > https://cr.openjdk.org/~jiangli/hermetic_java.pdf): >> > >> > - A customized launcher (with additional work for hermetic) executable >> > fully statically linked with JDK/VM static libraries (.a files), >> > application natives and dependencies (e.g. in .a static libraries) >> > - JDK lib/modules, JDK resource files >> > - Application classes and resource files >> > >> > Including a JDK library .a into the corresponding .jmod would require >> > extracting the .a for linking with the executable. In some systems >> > that may cause memory overhead due to the extracted copy of the .a >> > files. I think we should consider the memory overhead issue. >> > >> > One possibility (as Alan described in his response) is for jlink to >> > invoke the ld on the build system. jlink could pass the needed JDK >> > static libraries and libjvm.a (provided as part of the JDK binary) to >> > ld based on the modules required for the application. >> > >> >> I gave a bit more thoughts on this one. For jlink to trigger ld, it >> would need to know the complete linker options and inputs. Those >> include options and inputs related to the application part as well. In >> some usages, it might be easier to handle native linking separately >> and pass the linker output, the executable to jlink directly. Maybe we >> could consider supporting different modes for various usages >> requirements, from static libraries and native linking point of view: >> >> Mode #1 >> Support .jmod packaged natives static libraries, for both JDK/VM .a >> and application natives and dependencies. If the inputs to jlink >> include .jmods, jlink can extract the .a libraries and pass the >> information to ld to link the executable. >> >> Mode #2 >> Support separate .a as jlink input. Jlink could pass the path >> information to the .a libraries and other linker options to ld to >> create the executable. >> >> For both mode #1 and #2, jlink would then use the linker output >> executable to create the final hermetic image. >> >> Mode #3 >> Support a fully linked executable as a jlink input. When a linked >> executable is given to jlink, it can process it directly with other >> JDK data/files to create the final image, without native linking step. >> >> Any other thoughts and considerations? >> >> Best, >> Jiangli >> >> > > >> > > 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. >> > >> > An alternative with less memory overhead could be using application >> > modular JAR and separate .a as the input for jlink. >> > >> > > 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. >> > >> > Part of the current effort includes resolving the discovered symbol >> > collision issues with static linking. Will respond to your other email >> > on the symbol issue separately later. >> > >> > > >> > > 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. >> > >> > I think we would need both configure flag and special target for the >> > static builds. >> > >> > > 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. >> > >> > For the potential objcopy work to resolve symbol issues, we can add >> > that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We >> > have an internal prototype (not included in >> > https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done >> > by one of colleagues for localizing symbols in libfreetype using >> > objcopy. >> > >> > > >> > > 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". >> > >> > If we want to also build a fully statically linked launcher, maybe >> > --with-static-java? Being able to configure either dynamic, static or >> > both as you suggested also seems to be a good idea. >> > >> > > 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. >> > >> > Completely agree. It would be good to avoid recompiling the .o file >> > for static and dynamic builds. As proposed in >> > https://bugs.openjdk.org/browse/JDK-8303796: >> > >> > It's beneficial to be able to build both .so and .a from the same set >> > of .o files. That would involve some changes to handle the dynamic JDK >> > and static JDK difference at runtime, instead of relying on the >> > STATIC_BUILD macro. >> > >> > > >> > > 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. >> > >> > Renaming or redefining the symbol at build time could cause confusions >> > with debugging. That's a concern raised in >> > https://github.com/openjdk/jdk/pull/17456 discussions. >> > >> > Additionally, redefining symbols using tools like objcopy may not >> > handle member names referenced in string literals. For example, in >> > https://github.com/openjdk/jdk/pull/17456 additional changes are >> > needed in assembling and SA to reflect the symbol change. >> > >> > > >> > > 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? >> > >> > We have done some testing with jtreg SA related tests for the fully >> > statically linked `javastatic`. >> > >> > If we use objcopy to localize symbols in hotspot, it's not yet clear >> > what's the impact on SA. We could do some tests. The other question >> > that I raised is the supported gcc versions (for partial linking) >> > related to the solution. >> > >> > Best, >> > Jiangli >> > >> > > >> > > /Magnus >> > > From duke at openjdk.org Tue Apr 16 05:34:21 2024 From: duke at openjdk.org (duke) Date: Tue, 16 Apr 2024 05:34:21 GMT Subject: git: openjdk/leyden: premain: 3 new changesets Message-ID: <6c8c7fde-9416-4659-b354-e46a0b02b3f6@openjdk.org> Changeset: a98bb060 Author: Igor Veresov Date: 2024-04-08 19:36:54 +0000 URL: https://git.openjdk.org/leyden/commit/a98bb060581a75d7994a5c327884a1a5015e1890 Add missing reference traversal ! src/hotspot/share/oops/trainingData.cpp Changeset: 4b1f9091 Author: Igor Veresov Date: 2024-04-15 17:36:30 +0000 URL: https://git.openjdk.org/leyden/commit/4b1f9091870bf037b6add4cd778d8636ea1b9af6 Remove chaining of CTDs in a list. Capture only the ones we need. ! src/hotspot/share/oops/trainingData.cpp ! src/hotspot/share/oops/trainingData.hpp Changeset: 5f276f58 Author: Igor Veresov Date: 2024-04-15 17:51:22 +0000 URL: https://git.openjdk.org/leyden/commit/5f276f581b9e18bb55dcbb6a395f7e8b60d5288d Remove unused allocate() functions ! src/hotspot/share/oops/trainingData.cpp ! src/hotspot/share/oops/trainingData.hpp From duke at openjdk.org Tue Apr 16 06:29:47 2024 From: duke at openjdk.org (duke) Date: Tue, 16 Apr 2024 06:29:47 GMT Subject: git: openjdk/leyden: premain: Added build/test scripts for new demo: https://quarkus.io/guides/getting-started Message-ID: <4d625bd4-d1d5-4073-899f-543e1116e68e@openjdk.org> Changeset: 14902cb2 Author: iklam Date: 2024-04-15 18:05:44 +0000 URL: https://git.openjdk.org/leyden/commit/14902cb22e0c24aa26999f5da73aa05ec7f8c55f Added build/test scripts for new demo: https://quarkus.io/guides/getting-started ! test/hotspot/jtreg/premain/helidon-quickstart-se/Makefile + test/hotspot/jtreg/premain/lib/DemoSupport.gmk + test/hotspot/jtreg/premain/quarkus-getting-started/Main.java + test/hotspot/jtreg/premain/quarkus-getting-started/Makefile + test/hotspot/jtreg/runtime/cds/appcds/applications/QuarkusGettingStarted.java From volker.simonis at gmail.com Tue Apr 16 08:28:48 2024 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 16 Apr 2024 10:28:48 +0200 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> Message-ID: Hi, and sorry, I'm completely new to this discussion. I just wonder how `static-libs-image` is related to the `graal-builder-image` target which is available in mainline since JDK 11 and builds a static version of all the native libraries excluding the Hotspot ones? @Magnus: will the new, static build you're working on also cover `graal-builder-image` or will it be independent of it? From a quick look it seems that currently both `static-libs-image` and `graal-builder-image` are handled in `make/StaticLibsImage.gmk` but I'm not sure if they use the same build functionality. I just wondered why `graal-builder-image` hasn't been mentioned in this thread but maybe it's something as obvious as that it already is the same functionality anway? Thank you and best regards, Volker On Tue, Apr 16, 2024 at 3:02?AM Jiangli Zhou wrote: > > Magnus, thanks for the response. Please see comments inlined below. > > On Fri, Apr 12, 2024 at 4:52?AM Magnus Ihse Bursie > wrote: > > > > On 2024-04-02 21:16, Jiangli Zhou wrote: > > > > Hi Magnus, > > > > In today's zoom meeting with Alan, Ron, Liam and Chuck, we (briefly) discussed how to move forward contributing the static Java related changes (additional runtime fixes/enhancements on top of the existing static support in JDK) from https://github.com/openjdk/leyden/tree/hermetic-java-runtime to JDK mainline. > > > > Just a bit more details/context below, which may be useful for others reading this thread. > > > > The https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch currently contains following for supporting hermetic Java (without the launcher work for runtime support): > > > > 1. Build change for linking the Java launcher (as bin/javastatic) with JDK/hotspot static libraries (.a), mainly in https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk. The part for creating the complete sets of static libraries (including libjvm.a) has already been included in the mainline since last year. https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk is in a very raw state and is intended to demonstrate the capability of building a static Java launcher. > > > > Indeed. It is nowhere near being able to be integrated. > > > > The main purpose of StaticLink.gmk is to support the static-java-image > make target, which can be used to perform the actual static linking > step using libjvm.a and JDK static libraries. That currently doesn't > exist in the JDK mainline. Creating a "fully" statically linked Java > launcher is the first step (out of many) towards supporting > static/hermetic Java. > > As part of cleaning/refactoring/integrating for the static linking > step, we want to agree and decide/accept on the following: > > - Support the "fully" statically linked java launcher for testing and > demoing the capability of static JDK support, e.g. > - Support running jtreg testing using the "fully" statically linked > Java launcher > - Set up tests in github workflow to help detect any breaking > changes for static support, e.g. new symbol issues introduced by any > changes. There were some earlier discussions on this with Ron and Alan > during the zoom meetings. > - Which JDK native libraries to be statically linked with the new > launcher target? E.g. StaticLink.gmk currently excludes libjsound.a, > libawt_xawt.a, etc from statically linked with the launcher. > - Do we want more than one statically linked launcher target, based on > the set of linked native libraries? > > Based on the decisions of the above, the launcher static linking part > would mostly be in a different shape when it's integrated into the > mainline. That's why I referred to StaticLink.gmk as in a "very raw" > state. > > Here is a high-level view of the state of things for static support: > > (I) What we already have in the JDK mainline: > - Able to build a complete set of JDK/VM static libraries using > `static-libs-image` make target (necessary for supporting static JDK) > - Compilation for .o files are done separately for the static > libraries and dynamic library (ok for now) > > (II) What missing: > - Static linking step as mentioned above > > (III) What needs to be improved (require cleanups and refactoring, and > you mentioned some of those in your response as well): > - Support building both the static libraries and dynamic libraries > using the same set of .o files, instead of separately compiled .o > files. That helps improve build speed and reduce memory overhead for > building JDK. Your current refactoring work aims to help that. > - Clean up the usages of STATIC_BUILD macro. Most of the usages are in > test code. > - Other runtime fixes/enhancements in the leyden > https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch > > I think most work mentioned in III has dependencies on II. We need a > workable base to be able to build the "fully" statically linked > launcher for building and testing the work mentioned in III, when > integrating any of those to the JDK mainline. The makefile refactoring > work can be done in parallel but does not need to be completed before > we add the static linking step in JDK mainline. > > > > > 2. Additional runtime fixes/enhancements on top of the existing static support in JDK, e.g. support further lookup dynamic native library if the built-in native library cannot be found. > > > > 3. Some initial (prototype) work on supporting hermetic JDK resource files in the jimage (JDK modules image). > > > > To move forward, one of the earliest items needed is to add the capability of building the fully statically linked Java launcher in JDK mainline. The other static Java runtime changes can be followed up after the launcher linking part, so they can be built and tested as individual PRs created for the JDK mainline. Magnus, you have expressed interest in helping get the launcher linking part (refactor from https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk) into JDK mainline. What's your thought on prioritizing the launcher static linking part before other makefile clean ups for static libraries? > > > > Trust me, my absolute top priority now is working on getting the proper build support needed for Hermetic Java. I can't prioritize it any higher. > > Thanks! > > > > > I am not sure what you are asking for. We can't just merge StaticLink.gmk from your prototype. And even if we did, what good will it do you? > > Please see my comments above. > > > > > The problem you are running into is that the build system has not been designed to properly support static linking. There are already 3-4 hacks in place to get something sort-of useful out, but they are prone to breaking. I assume that we agree that for Hermetic Java to become a success, we need to have a stable foundation for static builds. > > > > The core problem of all static linking hacks is that they are not integrated in the right place. They need to be a core part of what NativeCompilation delivers, not something done in a separate file. To put it in other words, StaticLink.gmk from your branch do not need cleanup -- it needs to go away, and the functionality moved to the proper place. > > > > My approach is that NativeCompilation should support doing either only dynamic linking (as today), or static linking (as today with STATIC_LIBS or STATIC_BUILD), or both. The assumption is that the latter will be default, or at least should be tested by default in GHA. For this to work, we need to compile the source code to .o files only once, and then link these .o files either into a dynamic or a static library (or both). > > As of today, the leyden > https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch > can build a "fully" statically linked Java launcher. The issue of > compiling the dynamic and static libraries .o files separately is not > a blocker. It's good to have it resolved at some point of time. > > > > > This, in turn, require several changes: > > > > 1) The linking code needs to be cleaned up, and all technical debt needs to be resolved. This is what I have been doing since I started working on static builds for Hermetic Java. JDK-8329704 (which was integrated yesterday) was the first major milestone of this cleanup. Now, the path were to find a library created by the JDK (static or dynamic) is encapsulated in ResolveLibPath. This is currently a monster, but at least all knowledge is collected in a single location, instead of spread over the code base. Getting this simplified is the next step. > > > > 2) We need to stop passing the STATIC_BUILD define when compiling. This is partially addressed in your PR, where you have replaced #ifdef STATIC_BUILD with a dynamic lookup. But there is also the problem of JNI/JVMTI entry points. I have been pondering how we can compile the code in a way so we support both dynamic and static name resolution, and I think I have a solution. > > > > This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. > > Thumbs up! That seems to be a good direction. Currently in the leyden > branch, it first looks up the unique > JNI_OnLoad<_lib_name>|Agent_OnLoad<_lib_name> etc for built-in > libraries, then search for the dynamic libraries using the > conventional naming when necessary. e.g.: > > https://github.com/openjdk/leyden/commit/a5c886d2e85a0ff0c3712a5488ae61d8c9d7ba1a > https://github.com/openjdk/leyden/commit/1da8e3240e0bd27366d19f2e7dde386e46015135 > > When spec supports JNI_OnLoad_ and etc. for dynamic > libraries, we may still need to support the conventional naming > without the <_lib_name> part for existing libraries out there. > > > > > And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. > > > > A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. > > Thank you for taking this on! Potentially we could consider taking the > objcopy to localizing hotspot symbols on unix-like platforms, based on > https://github.com/openjdk/jdk/pull/17456 discussions. Additional > testing is still needed to verify the solution. > > > > > My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. > > Most of the JDK resources are now supported as hermetic jimage > (lib/modules) bundled in the > https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch. > The remaining sound.properties, ct.sym and .jfc files can be handled > later. Overally, that part of the work has confirmed the hermetic > jimage bundled solution is robust and helps resolve some of the > difficult start-up sequence issues observed when the hermetic resource > was implemented using JAR file based solution. > > It might be a good idea to follow up on the static linking discussion > in tomorrow's zoom meeting (hope you'll be able to join tomorrow). > > Thanks! > > Jiangli > > > > /Magnus > > > > > > > > Thanks! > > Jiangli > > > > On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: > >> > >> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: > >> > > >> > Hi Magnus, > >> > > >> > Thanks for looking into this from the build perspective. > >> > > >> > On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie > >> > wrote: > >> > > > >> > > 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. > >> > > >> > Some additional hermetic Java related references that are also useful: > >> > > >> > - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that > >> > links to the issues for resolving static linking issues so far > >> > - https://github.com/openjdk/jdk21/pull/26 is the enhancement for > >> > building the complete set of static libraries in JDK/VM, particularly > >> > including libjvm.a > >> > > >> > > > >> > > 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? > >> > > >> > I have a similar view as Alan responded in your other email thread. > >> > Things are still in the early stage for the general solution. > >> > > >> > In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime > >> > branch, when configuring JDK with --with-static-java=yes, the JDK > >> > binary contains the following extra artifacts: > >> > > >> > - static-libs/*.a: The complete set of JDK/VM static libraries > >> > - jdk/bin/javastatic: A demo Java launcher fully statically linked > >> > with the selected JDK .a libraries (e.g. it currently statically link > >> > with the headless) and libjvm.a. It's the standard Java launcher > >> > without additional work for hermetic Java. > >> > > >> > In our prototype for hermetic Java, we build the hermetic executable > >> > image (a single image) from the following input (see description on > >> > singlejar packaging tool in > >> > https://cr.openjdk.org/~jiangli/hermetic_java.pdf): > >> > > >> > - A customized launcher (with additional work for hermetic) executable > >> > fully statically linked with JDK/VM static libraries (.a files), > >> > application natives and dependencies (e.g. in .a static libraries) > >> > - JDK lib/modules, JDK resource files > >> > - Application classes and resource files > >> > > >> > Including a JDK library .a into the corresponding .jmod would require > >> > extracting the .a for linking with the executable. In some systems > >> > that may cause memory overhead due to the extracted copy of the .a > >> > files. I think we should consider the memory overhead issue. > >> > > >> > One possibility (as Alan described in his response) is for jlink to > >> > invoke the ld on the build system. jlink could pass the needed JDK > >> > static libraries and libjvm.a (provided as part of the JDK binary) to > >> > ld based on the modules required for the application. > >> > > >> > >> I gave a bit more thoughts on this one. For jlink to trigger ld, it > >> would need to know the complete linker options and inputs. Those > >> include options and inputs related to the application part as well. In > >> some usages, it might be easier to handle native linking separately > >> and pass the linker output, the executable to jlink directly. Maybe we > >> could consider supporting different modes for various usages > >> requirements, from static libraries and native linking point of view: > >> > >> Mode #1 > >> Support .jmod packaged natives static libraries, for both JDK/VM .a > >> and application natives and dependencies. If the inputs to jlink > >> include .jmods, jlink can extract the .a libraries and pass the > >> information to ld to link the executable. > >> > >> Mode #2 > >> Support separate .a as jlink input. Jlink could pass the path > >> information to the .a libraries and other linker options to ld to > >> create the executable. > >> > >> For both mode #1 and #2, jlink would then use the linker output > >> executable to create the final hermetic image. > >> > >> Mode #3 > >> Support a fully linked executable as a jlink input. When a linked > >> executable is given to jlink, it can process it directly with other > >> JDK data/files to create the final image, without native linking step. > >> > >> Any other thoughts and considerations? > >> > >> Best, > >> Jiangli > >> > >> > > > >> > > 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. > >> > > >> > An alternative with less memory overhead could be using application > >> > modular JAR and separate .a as the input for jlink. > >> > > >> > > 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. > >> > > >> > Part of the current effort includes resolving the discovered symbol > >> > collision issues with static linking. Will respond to your other email > >> > on the symbol issue separately later. > >> > > >> > > > >> > > 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. > >> > > >> > I think we would need both configure flag and special target for the > >> > static builds. > >> > > >> > > 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. > >> > > >> > For the potential objcopy work to resolve symbol issues, we can add > >> > that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We > >> > have an internal prototype (not included in > >> > https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done > >> > by one of colleagues for localizing symbols in libfreetype using > >> > objcopy. > >> > > >> > > > >> > > 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". > >> > > >> > If we want to also build a fully statically linked launcher, maybe > >> > --with-static-java? Being able to configure either dynamic, static or > >> > both as you suggested also seems to be a good idea. > >> > > >> > > 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. > >> > > >> > Completely agree. It would be good to avoid recompiling the .o file > >> > for static and dynamic builds. As proposed in > >> > https://bugs.openjdk.org/browse/JDK-8303796: > >> > > >> > It's beneficial to be able to build both .so and .a from the same set > >> > of .o files. That would involve some changes to handle the dynamic JDK > >> > and static JDK difference at runtime, instead of relying on the > >> > STATIC_BUILD macro. > >> > > >> > > > >> > > 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. > >> > > >> > Renaming or redefining the symbol at build time could cause confusions > >> > with debugging. That's a concern raised in > >> > https://github.com/openjdk/jdk/pull/17456 discussions. > >> > > >> > Additionally, redefining symbols using tools like objcopy may not > >> > handle member names referenced in string literals. For example, in > >> > https://github.com/openjdk/jdk/pull/17456 additional changes are > >> > needed in assembling and SA to reflect the symbol change. > >> > > >> > > > >> > > 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? > >> > > >> > We have done some testing with jtreg SA related tests for the fully > >> > statically linked `javastatic`. > >> > > >> > If we use objcopy to localize symbols in hotspot, it's not yet clear > >> > what's the impact on SA. We could do some tests. The other question > >> > that I raised is the supported gcc versions (for partial linking) > >> > related to the solution. > >> > > >> > Best, > >> > Jiangli > >> > > >> > > > >> > > /Magnus > >> > > From magnus.ihse.bursie at oracle.com Tue Apr 16 15:30:04 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 16 Apr 2024 17:30:04 +0200 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> Message-ID: <8852ba23-2830-4d23-ae52-11c554d8d750@oracle.com> Jiangli, First of all: I tried building the leyden branch "hermetic-java-runtime" but failed. :-( I tried some various attempts to work around the failures, but the javastatic file I ended up with were unable to start. What kind of environment are you using to build this branch? (OS, compiler, libc version, etc) Do you have any special configure flags that are required? I would very much like to test it out myself to check this static java launcher that you are creating. On 2024-04-16 03:01, Jiangli Zhou wrote: > The main purpose of StaticLink.gmk is to support the static-java-image > make target, which can be used to perform the actual static linking > step using libjvm.a and JDK static libraries. That currently doesn't > exist in the JDK mainline. Creating a "fully" statically linked Java > launcher is the first step (out of many) towards supporting > static/hermetic Java. I am still not sure it is the best design to have this in a separate file. You are in some way "just" creating a new launcher. > As part of cleaning/refactoring/integrating for the static linking > step, we want to agree and decide/accept on the following: > > - Support the "fully" statically linked java launcher for testing and > demoing the capability of static JDK support, e.g. > - Support running jtreg testing using the "fully" statically linked > Java launcher So how do you want to test native jtreg tests? By compiling the jtreg tests to native .a files and statically link with those as well, or to make this a hybrid mode where a statically linked launcher loads the jtreg tests dynamically? > - Set up tests in github workflow to help detect any breaking > changes for static support, e.g. new symbol issues introduced by any > changes. There were some earlier discussions on this with Ron and Alan > during the zoom meetings. If we do this correct, we should not have to worry about symbol conflicts. (Local symbols should all be hidden before creation of the static libraries.) That said, creating static libraries needs to be regularly tested or it will break. > - Which JDK native libraries to be statically linked with the new > launcher target? E.g. StaticLink.gmk currently excludes libjsound.a, > libawt_xawt.a, etc from statically linked with the launcher. That sounds rather arbitrarily. I would assume that a statically linked launcher should include native libraries from all included modules. If you are not interested in java.desktop native libraries, then you'd need to exclude java.desktop from the build. But my assumption here is that we need to build a solution that works with all modules included in the JDK, and that is what must be tested in GHA. > - Do we want more than one statically linked launcher target, based on > the set of linked native libraries? Do you mean that you want like "static-java-java.base-only", "static-java-eveything-but-java.desktop" etc? That does not sound like something that belongs in the makefiles. If you want to build a JDK that can only support a certain subset of modules, you need to specify those module in your build scripts as input to configure. > (II) What missing: > - Static linking step as mentioned above > > (III) What needs to be improved (require cleanups and refactoring, and > you mentioned some of those in your response as well): > - Support building both the static libraries and dynamic libraries > using the same set of .o files, instead of separately compiled .o > files. That helps improve build speed and reduce memory overhead for > building JDK. Your current refactoring work aims to help that. > - Clean up the usages of STATIC_BUILD macro. Most of the usages are in > test code. > - Other runtime fixes/enhancements in the leyden > https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch > > I think most work mentioned in III has dependencies on II. We need a > workable base to be able to build the "fully" statically linked > launcher for building and testing the work mentioned in III, when > integrating any of those to the JDK mainline. The makefile refactoring > work can be done in parallel but does not need to be completed before > we add the static linking step in JDK mainline. I'm not sure I understand why you consider (II) to be a prerequisite for the (III) issues. From my point of view, they are all mutually independent changes that needs to be done, and if anything, I think getting in code to create a statically linked launcher will probably be easier if we get further along on the other issues. In particular, I'd like to see changes to the STATIC_BUILD macro come in first. Ideally, we should not send in such a macro at all. The JNI_OnLoad stuff is bugging me mostly. > As of today, the leyden > https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch > can build a "fully" statically linked Java launcher. The issue of > compiling the dynamic and static libraries .o files separately is not > a blocker. It's good to have it resolved at some point of time. Weeeell, yes and no... It is not *technically* a blocker, but unless we can reuse the .o files, including static builds in the standard testing on GHA will effectively double the build time, and that is definitely not acceptable. And the alternative is to bring in static builds without having it regularly tested, which I don't think is acceptable either. So the conclusion is that getting static and dynamic libraries built from the same .o files is in effect a blocker for Hermetic Java. >> This, in turn, require several changes: >> >> 1) The linking code needs to be cleaned up, and all technical debt needs to be resolved. This is what I have been doing since I started working on static builds for Hermetic Java. JDK-8329704 (which was integrated yesterday) was the first major milestone of this cleanup. Now, the path were to find a library created by the JDK (static or dynamic) is encapsulated in ResolveLibPath. This is currently a monster, but at least all knowledge is collected in a single location, instead of spread over the code base. Getting this simplified is the next step. >> >> 2) We need to stop passing the STATIC_BUILD define when compiling. This is partially addressed in your PR, where you have replaced #ifdef STATIC_BUILD with a dynamic lookup. But there is also the problem of JNI/JVMTI entry points. I have been pondering how we can compile the code in a way so we support both dynamic and static name resolution, and I think I have a solution. >> >> This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. > Thumbs up! That seems to be a good direction. Currently in the leyden > branch, it first looks up the unique > JNI_OnLoad<_lib_name>|Agent_OnLoad<_lib_name> etc for built-in > libraries, then search for the dynamic libraries using the > conventional naming when necessary. e.g.: > > https://github.com/openjdk/leyden/commit/a5c886d2e85a0ff0c3712a5488ae61d8c9d7ba1a > https://github.com/openjdk/leyden/commit/1da8e3240e0bd27366d19f2e7dde386e46015135 > > When spec supports JNI_OnLoad_ and etc. for dynamic > libraries, we may still need to support the conventional naming > without the <_lib_name> part for existing libraries out there. That looks interesting. Basically, this is very similar to what I imagine needs to be done in the mainline. However, I don't think we can just change this code like that without a CSR? Or are we allowed to treat JDK-internal libraries different than the specification states? I would say getting this part into mainline should be the main focus right now, not the StaticLink.gmk file. And that includes getting any CSR approvals etc. > Thank you for taking this on! Potentially we could consider taking the > objcopy to localizing hotspot symbols on unix-like platforms, based on > https://github.com/openjdk/jdk/pull/17456 discussions. Additional > testing is still needed to verify the solution. We don't need any additional testing on that; proof of concept shows it works. It just needs to be implemented. With JDK-8330261 (pushed today), the ground is now prepared to get it done. It is next on my todo-list. > It might be a good idea to follow up on the static linking discussion > in tomorrow's zoom meeting (hope you'll be able to join tomorrow). I'll join but might be somewhat late due to family commitments. /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Tue Apr 16 15:40:09 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 16 Apr 2024 17:40:09 +0200 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> Message-ID: <4bda696b-eb73-497c-ac9d-b128fc887514@oracle.com> On 2024-04-16 10:28, Volker Simonis wrote: > Hi, and sorry, I'm completely new to this discussion. > > I just wonder how `static-libs-image` is related to the > `graal-builder-image` target which is available in mainline since JDK > 11 and builds a static version of all the native libraries excluding > the Hotspot ones? That's a very good question. You can also ask how it relates to --enable-static-build from JDK-8136556 which has been in the JDK since 9. :-) Or, to put in other words, we already have three different ways to produce static libraries in the JDK, each of them created more or less independently of the other. And now Hermetic Java wants to add a fourth. This is not a good situation. My intention here is to basically retire static-libs-image, graal-builder-image and --enable-static-build, and replace them with a more general solution that supports all these existing use cases, and the new use case from the StaticLink.gmk file that the Hermetic Java project wants to integrate. Unfortunately, this requires some delicate reverse-engineering of specifications (i.e. "why the heck did they do it like this???") to understand what the different use cases want to achieve. That is the main driver behind my recent work in clearing out technical debt in the native linking part of the build system. /Magnus > > @Magnus: will the new, static build you're working on also cover > `graal-builder-image` or will it be independent of it? From a quick > look it seems that currently both `static-libs-image` and > `graal-builder-image` are handled in `make/StaticLibsImage.gmk` but > I'm not sure if they use the same build functionality. I just wondered > why `graal-builder-image` hasn't been mentioned in this thread but > maybe it's something as obvious as that it already is the same > functionality anway? > > Thank you and best regards, > Volker > > On Tue, Apr 16, 2024 at 3:02?AM Jiangli Zhou wrote: >> Magnus, thanks for the response. Please see comments inlined below. >> >> On Fri, Apr 12, 2024 at 4:52?AM Magnus Ihse Bursie >> wrote: >>> On 2024-04-02 21:16, Jiangli Zhou wrote: >>> >>> Hi Magnus, >>> >>> In today's zoom meeting with Alan, Ron, Liam and Chuck, we (briefly) discussed how to move forward contributing the static Java related changes (additional runtime fixes/enhancements on top of the existing static support in JDK) from https://github.com/openjdk/leyden/tree/hermetic-java-runtime to JDK mainline. >>> >>> Just a bit more details/context below, which may be useful for others reading this thread. >>> >>> The https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch currently contains following for supporting hermetic Java (without the launcher work for runtime support): >>> >>> 1. Build change for linking the Java launcher (as bin/javastatic) with JDK/hotspot static libraries (.a), mainly in https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk. The part for creating the complete sets of static libraries (including libjvm.a) has already been included in the mainline since last year. https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk is in a very raw state and is intended to demonstrate the capability of building a static Java launcher. >>> >>> Indeed. It is nowhere near being able to be integrated. >>> >> The main purpose of StaticLink.gmk is to support the static-java-image >> make target, which can be used to perform the actual static linking >> step using libjvm.a and JDK static libraries. That currently doesn't >> exist in the JDK mainline. Creating a "fully" statically linked Java >> launcher is the first step (out of many) towards supporting >> static/hermetic Java. >> >> As part of cleaning/refactoring/integrating for the static linking >> step, we want to agree and decide/accept on the following: >> >> - Support the "fully" statically linked java launcher for testing and >> demoing the capability of static JDK support, e.g. >> - Support running jtreg testing using the "fully" statically linked >> Java launcher >> - Set up tests in github workflow to help detect any breaking >> changes for static support, e.g. new symbol issues introduced by any >> changes. There were some earlier discussions on this with Ron and Alan >> during the zoom meetings. >> - Which JDK native libraries to be statically linked with the new >> launcher target? E.g. StaticLink.gmk currently excludes libjsound.a, >> libawt_xawt.a, etc from statically linked with the launcher. >> - Do we want more than one statically linked launcher target, based on >> the set of linked native libraries? >> >> Based on the decisions of the above, the launcher static linking part >> would mostly be in a different shape when it's integrated into the >> mainline. That's why I referred to StaticLink.gmk as in a "very raw" >> state. >> >> Here is a high-level view of the state of things for static support: >> >> (I) What we already have in the JDK mainline: >> - Able to build a complete set of JDK/VM static libraries using >> `static-libs-image` make target (necessary for supporting static JDK) >> - Compilation for .o files are done separately for the static >> libraries and dynamic library (ok for now) >> >> (II) What missing: >> - Static linking step as mentioned above >> >> (III) What needs to be improved (require cleanups and refactoring, and >> you mentioned some of those in your response as well): >> - Support building both the static libraries and dynamic libraries >> using the same set of .o files, instead of separately compiled .o >> files. That helps improve build speed and reduce memory overhead for >> building JDK. Your current refactoring work aims to help that. >> - Clean up the usages of STATIC_BUILD macro. Most of the usages are in >> test code. >> - Other runtime fixes/enhancements in the leyden >> https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch >> >> I think most work mentioned in III has dependencies on II. We need a >> workable base to be able to build the "fully" statically linked >> launcher for building and testing the work mentioned in III, when >> integrating any of those to the JDK mainline. The makefile refactoring >> work can be done in parallel but does not need to be completed before >> we add the static linking step in JDK mainline. >> >>> 2. Additional runtime fixes/enhancements on top of the existing static support in JDK, e.g. support further lookup dynamic native library if the built-in native library cannot be found. >>> >>> 3. Some initial (prototype) work on supporting hermetic JDK resource files in the jimage (JDK modules image). >>> >>> To move forward, one of the earliest items needed is to add the capability of building the fully statically linked Java launcher in JDK mainline. The other static Java runtime changes can be followed up after the launcher linking part, so they can be built and tested as individual PRs created for the JDK mainline. Magnus, you have expressed interest in helping get the launcher linking part (refactor from https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk) into JDK mainline. What's your thought on prioritizing the launcher static linking part before other makefile clean ups for static libraries? >>> >>> Trust me, my absolute top priority now is working on getting the proper build support needed for Hermetic Java. I can't prioritize it any higher. >> Thanks! >> >>> I am not sure what you are asking for. We can't just merge StaticLink.gmk from your prototype. And even if we did, what good will it do you? >> Please see my comments above. >> >>> The problem you are running into is that the build system has not been designed to properly support static linking. There are already 3-4 hacks in place to get something sort-of useful out, but they are prone to breaking. I assume that we agree that for Hermetic Java to become a success, we need to have a stable foundation for static builds. >>> >>> The core problem of all static linking hacks is that they are not integrated in the right place. They need to be a core part of what NativeCompilation delivers, not something done in a separate file. To put it in other words, StaticLink.gmk from your branch do not need cleanup -- it needs to go away, and the functionality moved to the proper place. >>> >>> My approach is that NativeCompilation should support doing either only dynamic linking (as today), or static linking (as today with STATIC_LIBS or STATIC_BUILD), or both. The assumption is that the latter will be default, or at least should be tested by default in GHA. For this to work, we need to compile the source code to .o files only once, and then link these .o files either into a dynamic or a static library (or both). >> As of today, the leyden >> https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch >> can build a "fully" statically linked Java launcher. The issue of >> compiling the dynamic and static libraries .o files separately is not >> a blocker. It's good to have it resolved at some point of time. >> >>> This, in turn, require several changes: >>> >>> 1) The linking code needs to be cleaned up, and all technical debt needs to be resolved. This is what I have been doing since I started working on static builds for Hermetic Java. JDK-8329704 (which was integrated yesterday) was the first major milestone of this cleanup. Now, the path were to find a library created by the JDK (static or dynamic) is encapsulated in ResolveLibPath. This is currently a monster, but at least all knowledge is collected in a single location, instead of spread over the code base. Getting this simplified is the next step. >>> >>> 2) We need to stop passing the STATIC_BUILD define when compiling. This is partially addressed in your PR, where you have replaced #ifdef STATIC_BUILD with a dynamic lookup. But there is also the problem of JNI/JVMTI entry points. I have been pondering how we can compile the code in a way so we support both dynamic and static name resolution, and I think I have a solution. >>> >>> This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. >> Thumbs up! That seems to be a good direction. Currently in the leyden >> branch, it first looks up the unique >> JNI_OnLoad<_lib_name>|Agent_OnLoad<_lib_name> etc for built-in >> libraries, then search for the dynamic libraries using the >> conventional naming when necessary. e.g.: >> >> https://github.com/openjdk/leyden/commit/a5c886d2e85a0ff0c3712a5488ae61d8c9d7ba1a >> https://github.com/openjdk/leyden/commit/1da8e3240e0bd27366d19f2e7dde386e46015135 >> >> When spec supports JNI_OnLoad_ and etc. for dynamic >> libraries, we may still need to support the conventional naming >> without the <_lib_name> part for existing libraries out there. >> >>> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. >>> >>> A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. >> Thank you for taking this on! Potentially we could consider taking the >> objcopy to localizing hotspot symbols on unix-like platforms, based on >> https://github.com/openjdk/jdk/pull/17456 discussions. Additional >> testing is still needed to verify the solution. >> >>> My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. >> Most of the JDK resources are now supported as hermetic jimage >> (lib/modules) bundled in the >> https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch. >> The remaining sound.properties, ct.sym and .jfc files can be handled >> later. Overally, that part of the work has confirmed the hermetic >> jimage bundled solution is robust and helps resolve some of the >> difficult start-up sequence issues observed when the hermetic resource >> was implemented using JAR file based solution. >> >> It might be a good idea to follow up on the static linking discussion >> in tomorrow's zoom meeting (hope you'll be able to join tomorrow). >> >> Thanks! >> >> Jiangli >>> /Magnus >>> >>> >>> >>> Thanks! >>> Jiangli >>> >>> On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: >>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: >>>>> Hi Magnus, >>>>> >>>>> Thanks for looking into this from the build perspective. >>>>> >>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie >>>>> wrote: >>>>>> 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. >>>>> Some additional hermetic Java related references that are also useful: >>>>> >>>>> - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that >>>>> links to the issues for resolving static linking issues so far >>>>> - https://github.com/openjdk/jdk21/pull/26 is the enhancement for >>>>> building the complete set of static libraries in JDK/VM, particularly >>>>> including libjvm.a >>>>> >>>>>> 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? >>>>> I have a similar view as Alan responded in your other email thread. >>>>> Things are still in the early stage for the general solution. >>>>> >>>>> In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime >>>>> branch, when configuring JDK with --with-static-java=yes, the JDK >>>>> binary contains the following extra artifacts: >>>>> >>>>> - static-libs/*.a: The complete set of JDK/VM static libraries >>>>> - jdk/bin/javastatic: A demo Java launcher fully statically linked >>>>> with the selected JDK .a libraries (e.g. it currently statically link >>>>> with the headless) and libjvm.a. It's the standard Java launcher >>>>> without additional work for hermetic Java. >>>>> >>>>> In our prototype for hermetic Java, we build the hermetic executable >>>>> image (a single image) from the following input (see description on >>>>> singlejar packaging tool in >>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf): >>>>> >>>>> - A customized launcher (with additional work for hermetic) executable >>>>> fully statically linked with JDK/VM static libraries (.a files), >>>>> application natives and dependencies (e.g. in .a static libraries) >>>>> - JDK lib/modules, JDK resource files >>>>> - Application classes and resource files >>>>> >>>>> Including a JDK library .a into the corresponding .jmod would require >>>>> extracting the .a for linking with the executable. In some systems >>>>> that may cause memory overhead due to the extracted copy of the .a >>>>> files. I think we should consider the memory overhead issue. >>>>> >>>>> One possibility (as Alan described in his response) is for jlink to >>>>> invoke the ld on the build system. jlink could pass the needed JDK >>>>> static libraries and libjvm.a (provided as part of the JDK binary) to >>>>> ld based on the modules required for the application. >>>>> >>>> I gave a bit more thoughts on this one. For jlink to trigger ld, it >>>> would need to know the complete linker options and inputs. Those >>>> include options and inputs related to the application part as well. In >>>> some usages, it might be easier to handle native linking separately >>>> and pass the linker output, the executable to jlink directly. Maybe we >>>> could consider supporting different modes for various usages >>>> requirements, from static libraries and native linking point of view: >>>> >>>> Mode #1 >>>> Support .jmod packaged natives static libraries, for both JDK/VM .a >>>> and application natives and dependencies. If the inputs to jlink >>>> include .jmods, jlink can extract the .a libraries and pass the >>>> information to ld to link the executable. >>>> >>>> Mode #2 >>>> Support separate .a as jlink input. Jlink could pass the path >>>> information to the .a libraries and other linker options to ld to >>>> create the executable. >>>> >>>> For both mode #1 and #2, jlink would then use the linker output >>>> executable to create the final hermetic image. >>>> >>>> Mode #3 >>>> Support a fully linked executable as a jlink input. When a linked >>>> executable is given to jlink, it can process it directly with other >>>> JDK data/files to create the final image, without native linking step. >>>> >>>> Any other thoughts and considerations? >>>> >>>> Best, >>>> Jiangli >>>> >>>>>> 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. >>>>> An alternative with less memory overhead could be using application >>>>> modular JAR and separate .a as the input for jlink. >>>>> >>>>>> 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. >>>>> Part of the current effort includes resolving the discovered symbol >>>>> collision issues with static linking. Will respond to your other email >>>>> on the symbol issue separately later. >>>>> >>>>>> 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. >>>>> I think we would need both configure flag and special target for the >>>>> static builds. >>>>> >>>>>> 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. >>>>> For the potential objcopy work to resolve symbol issues, we can add >>>>> that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We >>>>> have an internal prototype (not included in >>>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done >>>>> by one of colleagues for localizing symbols in libfreetype using >>>>> objcopy. >>>>> >>>>>> 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". >>>>> If we want to also build a fully statically linked launcher, maybe >>>>> --with-static-java? Being able to configure either dynamic, static or >>>>> both as you suggested also seems to be a good idea. >>>>> >>>>>> 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. >>>>> Completely agree. It would be good to avoid recompiling the .o file >>>>> for static and dynamic builds. As proposed in >>>>> https://bugs.openjdk.org/browse/JDK-8303796: >>>>> >>>>> It's beneficial to be able to build both .so and .a from the same set >>>>> of .o files. That would involve some changes to handle the dynamic JDK >>>>> and static JDK difference at runtime, instead of relying on the >>>>> STATIC_BUILD macro. >>>>> >>>>>> 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. >>>>> Renaming or redefining the symbol at build time could cause confusions >>>>> with debugging. That's a concern raised in >>>>> https://github.com/openjdk/jdk/pull/17456 discussions. >>>>> >>>>> Additionally, redefining symbols using tools like objcopy may not >>>>> handle member names referenced in string literals. For example, in >>>>> https://github.com/openjdk/jdk/pull/17456 additional changes are >>>>> needed in assembling and SA to reflect the symbol change. >>>>> >>>>>> 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? >>>>> We have done some testing with jtreg SA related tests for the fully >>>>> statically linked `javastatic`. >>>>> >>>>> If we use objcopy to localize symbols in hotspot, it's not yet clear >>>>> what's the impact on SA. We could do some tests. The other question >>>>> that I raised is the supported gcc versions (for partial linking) >>>>> related to the solution. >>>>> >>>>> Best, >>>>> Jiangli >>>>> >>>>>> /Magnus >>>>>> From jianglizhou at google.com Tue Apr 16 16:20:11 2024 From: jianglizhou at google.com (Jiangli Zhou) Date: Tue, 16 Apr 2024 09:20:11 -0700 Subject: Questions about the Hermetic Java project In-Reply-To: <8852ba23-2830-4d23-ae52-11c554d8d750@oracle.com> References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <8852ba23-2830-4d23-ae52-11c554d8d750@oracle.com> Message-ID: On Tue, Apr 16, 2024 at 8:30?AM Magnus Ihse Bursie wrote: > > Jiangli, > > First of all: I tried building the leyden branch "hermetic-java-runtime" but failed. :-( I tried some various attempts to work around the failures, but the javastatic file I ended up with were unable to start. Magnus, I recall you mentioned that you had build issues during one of the zoom meetings earlier this year (didn't hear any follow-up on it). Let's get this resolved for you first. Can you please share the build failures/errors and runtime errors that you run into? Same questions about your build environment, as you asked below. > > What kind of environment are you using to build this branch? (OS, compiler, libc version, etc) Do you have any special configure flags that are required? For the leyden hermetic-java-runtime branch, I've only been building on Linux. I've used both gcc and clang. Yes, the branch requires `--with-static-java=yes`, e.g. bash configure --with-boot-jdk= --with-debug-level=slowdebug --with-static-java=yes I documented the build information in one of the comment messages. That's probably not the best place. I'll look for a better place. Let's discuss more on the rest of the topics below during our meeting today. We can update on the mailing list about the discussion, if others are interested. Best, Jiangli > > I would very much like to test it out myself to check this static java launcher that you are creating. > > On 2024-04-16 03:01, Jiangli Zhou wrote: > > The main purpose of StaticLink.gmk is to support the static-java-image > make target, which can be used to perform the actual static linking > step using libjvm.a and JDK static libraries. That currently doesn't > exist in the JDK mainline. Creating a "fully" statically linked Java > launcher is the first step (out of many) towards supporting > static/hermetic Java. > > I am still not sure it is the best design to have this in a separate file. You are in some way "just" creating a new launcher. > > As part of cleaning/refactoring/integrating for the static linking > step, we want to agree and decide/accept on the following: > > - Support the "fully" statically linked java launcher for testing and > demoing the capability of static JDK support, e.g. > - Support running jtreg testing using the "fully" statically linked > Java launcher > > So how do you want to test native jtreg tests? By compiling the jtreg tests to native .a files and statically link with those as well, or to make this a hybrid mode where a statically linked launcher loads the jtreg tests dynamically? > > - Set up tests in github workflow to help detect any breaking > changes for static support, e.g. new symbol issues introduced by any > changes. There were some earlier discussions on this with Ron and Alan > during the zoom meetings. > > If we do this correct, we should not have to worry about symbol conflicts. (Local symbols should all be hidden before creation of the static libraries.) That said, creating static libraries needs to be regularly tested or it will break. > > - Which JDK native libraries to be statically linked with the new > launcher target? E.g. StaticLink.gmk currently excludes libjsound.a, > libawt_xawt.a, etc from statically linked with the launcher. > > That sounds rather arbitrarily. I would assume that a statically linked launcher should include native libraries from all included modules. If you are not interested in java.desktop native libraries, then you'd need to exclude java.desktop from the build. But my assumption here is that we need to build a solution that works with all modules included in the JDK, and that is what must be tested in GHA. > > - Do we want more than one statically linked launcher target, based on > the set of linked native libraries? > > Do you mean that you want like "static-java-java.base-only", "static-java-eveything-but-java.desktop" etc? That does not sound like something that belongs in the makefiles. If you want to build a JDK that can only support a certain subset of modules, you need to specify those module in your build scripts as input to configure. > > (II) What missing: > - Static linking step as mentioned above > > (III) What needs to be improved (require cleanups and refactoring, and > you mentioned some of those in your response as well): > - Support building both the static libraries and dynamic libraries > using the same set of .o files, instead of separately compiled .o > files. That helps improve build speed and reduce memory overhead for > building JDK. Your current refactoring work aims to help that. > - Clean up the usages of STATIC_BUILD macro. Most of the usages are in > test code. > - Other runtime fixes/enhancements in the leyden > https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch > > I think most work mentioned in III has dependencies on II. We need a > workable base to be able to build the "fully" statically linked > launcher for building and testing the work mentioned in III, when > integrating any of those to the JDK mainline. The makefile refactoring > work can be done in parallel but does not need to be completed before > we add the static linking step in JDK mainline. > > I'm not sure I understand why you consider (II) to be a prerequisite for the (III) issues. From my point of view, they are all mutually independent changes that needs to be done, and if anything, I think getting in code to create a statically linked launcher will probably be easier if we get further along on the other issues. > > In particular, I'd like to see changes to the STATIC_BUILD macro come in first. Ideally, we should not send in such a macro at all. The JNI_OnLoad stuff is bugging me mostly. > > As of today, the leyden > https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch > can build a "fully" statically linked Java launcher. The issue of > compiling the dynamic and static libraries .o files separately is not > a blocker. It's good to have it resolved at some point of time. > > Weeeell, yes and no... It is not *technically* a blocker, but unless we can reuse the .o files, including static builds in the standard testing on GHA will effectively double the build time, and that is definitely not acceptable. And the alternative is to bring in static builds without having it regularly tested, which I don't think is acceptable either. > > So the conclusion is that getting static and dynamic libraries built from the same .o files is in effect a blocker for Hermetic Java. > > This, in turn, require several changes: > > 1) The linking code needs to be cleaned up, and all technical debt needs to be resolved. This is what I have been doing since I started working on static builds for Hermetic Java. JDK-8329704 (which was integrated yesterday) was the first major milestone of this cleanup. Now, the path were to find a library created by the JDK (static or dynamic) is encapsulated in ResolveLibPath. This is currently a monster, but at least all knowledge is collected in a single location, instead of spread over the code base. Getting this simplified is the next step. > > 2) We need to stop passing the STATIC_BUILD define when compiling. This is partially addressed in your PR, where you have replaced #ifdef STATIC_BUILD with a dynamic lookup. But there is also the problem of JNI/JVMTI entry points. I have been pondering how we can compile the code in a way so we support both dynamic and static name resolution, and I think I have a solution. > > This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. > > Thumbs up! That seems to be a good direction. Currently in the leyden > branch, it first looks up the unique > JNI_OnLoad<_lib_name>|Agent_OnLoad<_lib_name> etc for built-in > libraries, then search for the dynamic libraries using the > conventional naming when necessary. e.g.: > > https://github.com/openjdk/leyden/commit/a5c886d2e85a0ff0c3712a5488ae61d8c9d7ba1a > https://github.com/openjdk/leyden/commit/1da8e3240e0bd27366d19f2e7dde386e46015135 > > When spec supports JNI_OnLoad_ and etc. for dynamic > libraries, we may still need to support the conventional naming > without the <_lib_name> part for existing libraries out there. > > That looks interesting. Basically, this is very similar to what I imagine needs to be done in the mainline. However, I don't think we can just change this code like that without a CSR? Or are we allowed to treat JDK-internal libraries different than the specification states? > > I would say getting this part into mainline should be the main focus right now, not the StaticLink.gmk file. And that includes getting any CSR approvals etc. > > Thank you for taking this on! Potentially we could consider taking the > objcopy to localizing hotspot symbols on unix-like platforms, based on > https://github.com/openjdk/jdk/pull/17456 discussions. Additional > testing is still needed to verify the solution. > > We don't need any additional testing on that; proof of concept shows it works. It just needs to be implemented. With JDK-8330261 (pushed today), the ground is now prepared to get it done. It is next on my todo-list. > > It might be a good idea to follow up on the static linking discussion > in tomorrow's zoom meeting (hope you'll be able to join tomorrow). > > I'll join but might be somewhat late due to family commitments. > > /Magnus From sgehwolf at redhat.com Tue Apr 16 16:54:35 2024 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 16 Apr 2024 18:54:35 +0200 Subject: Questions about the Hermetic Java project In-Reply-To: <4bda696b-eb73-497c-ac9d-b128fc887514@oracle.com> References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <4bda696b-eb73-497c-ac9d-b128fc887514@oracle.com> Message-ID: <2bcb09faef4c8e6bd1386c8a705ac243dbfe16ec.camel@redhat.com> Hi, On Tue, 2024-04-16 at 17:40 +0200, Magnus Ihse Bursie wrote: > On 2024-04-16 10:28, Volker Simonis wrote: > > > Hi, and sorry, I'm completely new to this discussion. > > > > I just wonder how `static-libs-image` is related to the > > `graal-builder-image` target which is available in mainline since JDK > > 11 and builds a static version of all the native libraries excluding > > the Hotspot ones? I cannot comment on the static-libs-image part, but graal-builder-image was my doing[1]. It's a vehicle to build an OpenJDK with static libs in lib/static which is sufficient to use as a from-source version build of OpenJDK to build Mandrel[2] or GraalVM, which is convenient. For graal-builder-image, the result must not include libjvm.a in lib/static of /graal-builder-jdk. So yes, the two are related. Thanks, Severin [1] https://bugs.openjdk.org/browse/JDK-8236921 [2] https://github.com/graalvm/mandrel > That's a very good question. You can also ask how it relates to > --enable-static-build from JDK-8136556 which has been in the JDK since > 9. :-) > > Or, to put in other words, we already have three different ways to > produce static libraries in the JDK, each of them created more or less > independently of the other. And now Hermetic Java wants to add a fourth. > > This is not a good situation. > > My intention here is to basically retire static-libs-image, > graal-builder-image and --enable-static-build, and replace them with a > more general solution that supports all these existing use cases, and > the new use case from the StaticLink.gmk file that the Hermetic Java > project wants to integrate. > > Unfortunately, this requires some delicate reverse-engineering of > specifications (i.e. "why the heck did they do it like this???") to > understand what the different use cases want to achieve. That is the > main driver behind my recent work in clearing out technical debt in the > native linking part of the build system. > > /Magnus > > > > > > @Magnus: will the new, static build you're working on also cover > > `graal-builder-image` or will it be independent of it? From a quick > > look it seems that currently both `static-libs-image` and > > `graal-builder-image` are handled in `make/StaticLibsImage.gmk` but > > I'm not sure if they use the same build functionality. I just wondered > > why `graal-builder-image` hasn't been mentioned in this thread but > > maybe it's something as obvious as that it already is the same > > functionality anway? > > > > Thank you and best regards, > > Volker > > > > On Tue, Apr 16, 2024 at 3:02?AM Jiangli Zhou wrote: > > > Magnus, thanks for the response. Please see comments inlined below. > > > > > > On Fri, Apr 12, 2024 at 4:52?AM Magnus Ihse Bursie > > > wrote: > > > > On 2024-04-02 21:16, Jiangli Zhou wrote: > > > > > > > > Hi Magnus, > > > > > > > > In today's zoom meeting with Alan, Ron, Liam and Chuck, we (briefly) discussed how to move forward contributing the static Java related changes (additional runtime fixes/enhancements on top of the existing static support in JDK) from https://github.com/openjdk/leyden/tree/hermetic-java-runtime?to JDK mainline. > > > > > > > > Just a bit more details/context below, which may be useful for others reading this thread. > > > > > > > > The https://github.com/openjdk/leyden/tree/hermetic-java-runtime?branch currently contains following for supporting hermetic Java (without the launcher work for runtime support): > > > > > > > > 1. Build change for linking the Java launcher (as bin/javastatic) with JDK/hotspot static libraries (.a), mainly in https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk. The part for creating the complete sets of static libraries (including libjvm.a) has already been included in the mainline since last year. https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk?is in a very raw state and is intended to demonstrate the capability of building a static Java launcher. > > > > > > > > Indeed. It is nowhere near being able to be integrated. > > > > > > > The main purpose of StaticLink.gmk is to support the static-java-image > > > make target, which can be used to perform the actual static linking > > > step using libjvm.a and JDK static libraries. That currently doesn't > > > exist in the JDK mainline. Creating a "fully" statically linked Java > > > launcher is the first step (out of many) towards supporting > > > static/hermetic Java. > > > > > > As part of cleaning/refactoring/integrating for the static linking > > > step, we want to agree and decide/accept on the following: > > > > > > - Support the "fully" statically linked java launcher for testing and > > > demoing the capability of static JDK support, e.g. > > > ?? - Support running jtreg testing using the "fully" statically linked > > > Java launcher > > > ?? - Set up tests in github workflow to help detect any breaking > > > changes for static support, e.g. new symbol issues introduced by any > > > changes. There were some earlier discussions on this with Ron and Alan > > > during the zoom meetings. > > > - Which JDK native libraries to be statically linked with the new > > > launcher target? E.g. StaticLink.gmk currently excludes libjsound.a, > > > libawt_xawt.a, etc from statically linked with the launcher. > > > - Do we want more than one statically linked launcher target, based on > > > the set of linked native libraries? > > > > > > Based on the decisions of the above, the launcher static linking part > > > would mostly be in a different shape when it's integrated into the > > > mainline. That's why I referred to StaticLink.gmk as in a "very raw" > > > state. > > > > > > Here is a high-level view of the state of things for static support: > > > > > > (I)? What we already have in the JDK mainline: > > > - Able to build a complete set of JDK/VM static libraries using > > > `static-libs-image` make target (necessary for supporting static JDK) > > > - Compilation for .o files are done separately for the static > > > libraries and dynamic library (ok for now) > > > > > > (II) What missing: > > > - Static linking step as mentioned above > > > > > > (III) What needs to be improved (require cleanups and refactoring, and > > > you mentioned some of those in your response as well): > > > - Support building both the static libraries and dynamic libraries > > > using the same set of .o files, instead of separately compiled .o > > > files. That helps improve build speed and reduce memory overhead for > > > building JDK. Your current refactoring work aims to help that. > > > - Clean up the usages of STATIC_BUILD macro. Most of the usages are in > > > test code. > > > - Other runtime fixes/enhancements in the leyden > > > https://github.com/openjdk/leyden/tree/hermetic-java-runtime?branch > > > > > > I think most work mentioned in III has dependencies on II. We need a > > > workable base to be able to build the "fully" statically linked > > > launcher for building and testing the work mentioned in III, when > > > integrating any of those to the JDK mainline. The makefile refactoring > > > work can be done in parallel but does not need to be completed before > > > we add the static linking step in JDK mainline. > > > > > > > 2. Additional runtime fixes/enhancements on top of the existing static support in JDK, e.g. support further lookup dynamic native library if the built-in native library cannot be found. > > > > > > > > 3. Some initial (prototype) work on supporting hermetic JDK resource files in the jimage (JDK modules image). > > > > > > > > To move forward, one of the earliest items needed is to add the capability of building the fully statically linked Java launcher in JDK mainline. The other static Java runtime changes can be followed up after the launcher linking part, so they can be built and tested as individual PRs created for the JDK mainline. Magnus, you have expressed interest in helping get the launcher linking part (refactor from https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk) into JDK mainline. What's your thought on prioritizing the launcher static linking part before other makefile clean ups for static libraries? > > > > > > > > Trust me, my absolute top priority now is working on getting the proper build support needed for Hermetic Java. I can't prioritize it any higher. > > > Thanks! > > > > > > > I am not sure what you are asking for. We can't just merge StaticLink.gmk from your prototype. And even if we did, what good will it do you? > > > Please see my comments above. > > > > > > > The problem you are running into is that the build system has not been designed to properly support static linking. There are already 3-4 hacks in place to get something sort-of useful out, but they are prone to breaking. I assume that we agree that for Hermetic Java to become a success, we need to have a stable foundation for static builds. > > > > > > > > The core problem of all static linking hacks is that they are not integrated in the right place. They need to be a core part of what NativeCompilation delivers, not something done in a separate file. To put it in other words, StaticLink.gmk from your branch do not need cleanup -- it needs to go away, and the functionality moved to the proper place. > > > > > > > > My approach is that NativeCompilation should support doing either only dynamic linking (as today), or static linking (as today with STATIC_LIBS or STATIC_BUILD), or both. The assumption is that the latter will be default, or at least should be tested by default in GHA. For this to work, we need to compile the source code to .o files only once, and then link these .o files either into a dynamic or a static library (or both). > > > As of today, the leyden > > > https://github.com/openjdk/leyden/tree/hermetic-java-runtime?branch > > > can build a "fully" statically linked Java launcher. The issue of > > > compiling the dynamic and static libraries .o files separately is not > > > a blocker. It's good to have it resolved at some point of time. > > > > > > > This, in turn, require several changes: > > > > > > > > 1) The linking code needs to be cleaned up, and all technical debt needs to be resolved. This is what I have been doing since I started working on static builds for Hermetic Java. JDK-8329704 (which was integrated yesterday) was the first major milestone of this cleanup. Now, the path were to find a library created by the JDK (static or dynamic) is encapsulated in ResolveLibPath. This is currently a monster, but at least all knowledge is collected in a single location, instead of spread over the code base. Getting this simplified is the next step. > > > > > > > > 2) We need to stop passing the STATIC_BUILD define when compiling. This is partially addressed in your PR, where you have replaced #ifdef STATIC_BUILD with a dynamic lookup. But there is also the problem of JNI/JVMTI entry points. I have been pondering how we can compile the code in a way so we support both dynamic and static name resolution, and I think I have a solution. > > > > > > > > This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. > > > Thumbs up! That seems to be a good direction. Currently in the leyden > > > branch, it first looks up the unique > > > JNI_OnLoad<_lib_name>|Agent_OnLoad<_lib_name> etc for built-in > > > libraries, then search for the dynamic libraries using the > > > conventional naming when necessary. e.g.: > > > > > > https://github.com/openjdk/leyden/commit/a5c886d2e85a0ff0c3712a5488ae61d8c9d7ba1a > > > https://github.com/openjdk/leyden/commit/1da8e3240e0bd27366d19f2e7dde386e46015135 > > > > > > When spec supports JNI_OnLoad_ and etc. for dynamic > > > libraries, we may still need to support the conventional naming > > > without the <_lib_name> part for existing libraries out there. > > > > > > > And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. > > > > > > > > A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. > > > Thank you for taking this on! Potentially we could consider taking the > > > objcopy to localizing hotspot symbols on unix-like platforms, based on > > > https://github.com/openjdk/jdk/pull/17456?discussions. Additional > > > testing is still needed to verify the solution. > > > > > > > My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. > > > Most of the JDK resources are now supported as hermetic jimage > > > (lib/modules) bundled in the > > > https://github.com/openjdk/leyden/tree/hermetic-java-runtime?branch. > > > The remaining sound.properties, ct.sym and .jfc files can be handled > > > later. Overally, that part of the work has confirmed the hermetic > > > jimage bundled solution is robust and helps resolve some of the > > > difficult start-up sequence issues observed when the hermetic resource > > > was implemented using JAR file based solution. > > > > > > It might be a good idea to follow up on the static linking discussion > > > in tomorrow's zoom meeting (hope you'll be able to join tomorrow). > > > > > > Thanks! > > > > > > Jiangli > > > > /Magnus > > > > > > > > > > > > > > > > Thanks! > > > > Jiangli > > > > > > > > On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: > > > > > On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: > > > > > > Hi Magnus, > > > > > > > > > > > > Thanks for looking into this from the build perspective. > > > > > > > > > > > > On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie > > > > > > wrote: > > > > > > > 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. > > > > > > Some additional hermetic Java related references that are also useful: > > > > > > > > > > > > - https://bugs.openjdk.org/browse/JDK-8303796?is an umbrella bug that > > > > > > links to the issues for resolving static linking issues so far > > > > > > - https://github.com/openjdk/jdk21/pull/26?is the enhancement for > > > > > > building the complete set of static libraries in JDK/VM, particularly > > > > > > including libjvm.a > > > > > > > > > > > > > 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? > > > > > > I have a similar view as Alan responded in your other email thread. > > > > > > Things are still in the early stage for the general solution. > > > > > > > > > > > > In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime > > > > > > branch, when configuring JDK with --with-static-java=yes, the JDK > > > > > > binary contains the following extra artifacts: > > > > > > > > > > > > - static-libs/*.a: The complete set of JDK/VM static libraries > > > > > > - jdk/bin/javastatic: A demo Java launcher fully statically linked > > > > > > with the selected JDK .a libraries (e.g. it currently statically link > > > > > > with the headless) and libjvm.a. It's the standard Java launcher > > > > > > without additional work for hermetic Java. > > > > > > > > > > > > In our prototype for hermetic Java, we build the hermetic executable > > > > > > image (a single image) from the following input (see description on > > > > > > singlejar packaging tool in > > > > > > https://cr.openjdk.org/~jiangli/hermetic_java.pdf): > > > > > > > > > > > > - A customized launcher (with additional work for hermetic) executable > > > > > > fully statically linked with JDK/VM static libraries (.a files), > > > > > > application natives and dependencies (e.g. in .a static libraries) > > > > > > - JDK lib/modules, JDK resource files > > > > > > - Application classes and resource files > > > > > > > > > > > > Including a JDK library .a into the corresponding .jmod would require > > > > > > extracting the .a for linking with the executable. In some systems > > > > > > that may cause memory overhead due to the extracted copy of the .a > > > > > > files. I think we should consider the memory overhead issue. > > > > > > > > > > > > One possibility (as Alan described in his response) is for jlink to > > > > > > invoke the ld on the build system. jlink could pass the needed JDK > > > > > > static libraries and libjvm.a (provided as part of the JDK binary) to > > > > > > ld based on the modules required for the application. > > > > > > > > > > > I gave a bit more thoughts on this one. For jlink to trigger ld, it > > > > > would need to know the complete linker options and inputs. Those > > > > > include options and inputs related to the application part as well. In > > > > > some usages, it might be easier to handle native linking separately > > > > > and pass the linker output, the executable to jlink directly. Maybe we > > > > > could consider supporting different modes for various usages > > > > > requirements, from static libraries and native linking point of view: > > > > > > > > > > Mode #1 > > > > > Support .jmod packaged natives static libraries, for both JDK/VM .a > > > > > and application natives and dependencies. If the inputs to jlink > > > > > include .jmods, jlink can extract the .a libraries and pass the > > > > > information to ld to link the executable. > > > > > > > > > > Mode #2 > > > > > Support separate .a as jlink input. Jlink could pass the path > > > > > information to the .a libraries and other linker options to ld to > > > > > create the executable. > > > > > > > > > > For both mode #1 and #2, jlink would then use the linker output > > > > > executable to create the final hermetic image. > > > > > > > > > > Mode #3 > > > > > Support a fully linked executable as a jlink input. When a linked > > > > > executable is given to jlink, it can process it directly with other > > > > > JDK data/files to create the final image, without native linking step. > > > > > > > > > > Any other thoughts and considerations? > > > > > > > > > > Best, > > > > > Jiangli > > > > > > > > > > > > 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. > > > > > > An alternative with less memory overhead could be using application > > > > > > modular JAR and separate .a as the input for jlink. > > > > > > > > > > > > > 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. > > > > > > Part of the current effort includes resolving the discovered symbol > > > > > > collision issues with static linking. Will respond to your other email > > > > > > on the symbol issue separately later. > > > > > > > > > > > > > 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. > > > > > > I think we would need both configure flag and special target for the > > > > > > static builds. > > > > > > > > > > > > > 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. > > > > > > For the potential objcopy work to resolve symbol issues, we can add > > > > > > that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We > > > > > > have an internal prototype (not included in > > > > > > https://github.com/openjdk/leyden/tree/hermetic-java-runtime?yet) done > > > > > > by one of colleagues for localizing symbols in libfreetype using > > > > > > objcopy. > > > > > > > > > > > > > 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". > > > > > > If we want to also build a fully statically linked launcher, maybe > > > > > > --with-static-java? Being able to configure either dynamic, static or > > > > > > both as you suggested also seems to be a good idea. > > > > > > > > > > > > > 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. > > > > > > Completely agree. It would be good to avoid recompiling the .o file > > > > > > for static and dynamic builds. As proposed in > > > > > > https://bugs.openjdk.org/browse/JDK-8303796: > > > > > > > > > > > > It's beneficial to be able to build both .so and .a from the same set > > > > > > of .o files. That would involve some changes to handle the dynamic JDK > > > > > > and static JDK difference at runtime, instead of relying on the > > > > > > STATIC_BUILD macro. > > > > > > > > > > > > > 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. > > > > > > Renaming or redefining the symbol at build time could cause confusions > > > > > > with debugging. That's a concern raised in > > > > > > https://github.com/openjdk/jdk/pull/17456?discussions. > > > > > > > > > > > > Additionally, redefining symbols using tools like objcopy may not > > > > > > handle member names referenced in string literals. For example, in > > > > > > https://github.com/openjdk/jdk/pull/17456?additional changes are > > > > > > needed in assembling and SA to reflect the symbol change. > > > > > > > > > > > > > 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? > > > > > > We have done some testing with jtreg SA related tests for the fully > > > > > > statically linked `javastatic`. > > > > > > > > > > > > If we use objcopy to localize symbols in hotspot, it's not yet clear > > > > > > what's the impact on SA. We could do some tests. The other question > > > > > > that I raised is the supported gcc versions (for partial linking) > > > > > > related to the solution. > > > > > > > > > > > > Best, > > > > > > Jiangli > > > > > > > > > > > > > /Magnus > > > > > > > > From volker.simonis at gmail.com Tue Apr 16 17:03:35 2024 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 16 Apr 2024 19:03:35 +0200 Subject: Questions about the Hermetic Java project In-Reply-To: <4bda696b-eb73-497c-ac9d-b128fc887514@oracle.com> References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <4bda696b-eb73-497c-ac9d-b128fc887514@oracle.com> Message-ID: On Tue, Apr 16, 2024 at 5:40?PM Magnus Ihse Bursie wrote: > > On 2024-04-16 10:28, Volker Simonis wrote: > > > Hi, and sorry, I'm completely new to this discussion. > > > > I just wonder how `static-libs-image` is related to the > > `graal-builder-image` target which is available in mainline since JDK > > 11 and builds a static version of all the native libraries excluding > > the Hotspot ones? > > That's a very good question. You can also ask how it relates to > --enable-static-build from JDK-8136556 which has been in the JDK since > 9. :-) > > Or, to put in other words, we already have three different ways to > produce static libraries in the JDK, each of them created more or less > independently of the other. And now Hermetic Java wants to add a fourth. > > This is not a good situation. > > My intention here is to basically retire static-libs-image, > graal-builder-image and --enable-static-build, and replace them with a > more general solution that supports all these existing use cases, and > the new use case from the StaticLink.gmk file that the Hermetic Java > project wants to integrate. > > Unfortunately, this requires some delicate reverse-engineering of > specifications (i.e. "why the heck did they do it like this???") to > understand what the different use cases want to achieve. That is the > main driver behind my recent work in clearing out technical debt in the > native linking part of the build system. Thanks for the more detailed background information Magnus. Consolidating the different possibilities for creating static libraries definitely looks like the right thing to do. I've added Doug from the GraalVM team on CC just in case he's not already aware of this refactoring. Regards, Volker > > /Magnus > > > > > > @Magnus: will the new, static build you're working on also cover > > `graal-builder-image` or will it be independent of it? From a quick > > look it seems that currently both `static-libs-image` and > > `graal-builder-image` are handled in `make/StaticLibsImage.gmk` but > > I'm not sure if they use the same build functionality. I just wondered > > why `graal-builder-image` hasn't been mentioned in this thread but > > maybe it's something as obvious as that it already is the same > > functionality anway? > > > > Thank you and best regards, > > Volker > > > > On Tue, Apr 16, 2024 at 3:02?AM Jiangli Zhou wrote: > >> Magnus, thanks for the response. Please see comments inlined below. > >> > >> On Fri, Apr 12, 2024 at 4:52?AM Magnus Ihse Bursie > >> wrote: > >>> On 2024-04-02 21:16, Jiangli Zhou wrote: > >>> > >>> Hi Magnus, > >>> > >>> In today's zoom meeting with Alan, Ron, Liam and Chuck, we (briefly) discussed how to move forward contributing the static Java related changes (additional runtime fixes/enhancements on top of the existing static support in JDK) from https://github.com/openjdk/leyden/tree/hermetic-java-runtime to JDK mainline. > >>> > >>> Just a bit more details/context below, which may be useful for others reading this thread. > >>> > >>> The https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch currently contains following for supporting hermetic Java (without the launcher work for runtime support): > >>> > >>> 1. Build change for linking the Java launcher (as bin/javastatic) with JDK/hotspot static libraries (.a), mainly in https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk. The part for creating the complete sets of static libraries (including libjvm.a) has already been included in the mainline since last year. https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk is in a very raw state and is intended to demonstrate the capability of building a static Java launcher. > >>> > >>> Indeed. It is nowhere near being able to be integrated. > >>> > >> The main purpose of StaticLink.gmk is to support the static-java-image > >> make target, which can be used to perform the actual static linking > >> step using libjvm.a and JDK static libraries. That currently doesn't > >> exist in the JDK mainline. Creating a "fully" statically linked Java > >> launcher is the first step (out of many) towards supporting > >> static/hermetic Java. > >> > >> As part of cleaning/refactoring/integrating for the static linking > >> step, we want to agree and decide/accept on the following: > >> > >> - Support the "fully" statically linked java launcher for testing and > >> demoing the capability of static JDK support, e.g. > >> - Support running jtreg testing using the "fully" statically linked > >> Java launcher > >> - Set up tests in github workflow to help detect any breaking > >> changes for static support, e.g. new symbol issues introduced by any > >> changes. There were some earlier discussions on this with Ron and Alan > >> during the zoom meetings. > >> - Which JDK native libraries to be statically linked with the new > >> launcher target? E.g. StaticLink.gmk currently excludes libjsound.a, > >> libawt_xawt.a, etc from statically linked with the launcher. > >> - Do we want more than one statically linked launcher target, based on > >> the set of linked native libraries? > >> > >> Based on the decisions of the above, the launcher static linking part > >> would mostly be in a different shape when it's integrated into the > >> mainline. That's why I referred to StaticLink.gmk as in a "very raw" > >> state. > >> > >> Here is a high-level view of the state of things for static support: > >> > >> (I) What we already have in the JDK mainline: > >> - Able to build a complete set of JDK/VM static libraries using > >> `static-libs-image` make target (necessary for supporting static JDK) > >> - Compilation for .o files are done separately for the static > >> libraries and dynamic library (ok for now) > >> > >> (II) What missing: > >> - Static linking step as mentioned above > >> > >> (III) What needs to be improved (require cleanups and refactoring, and > >> you mentioned some of those in your response as well): > >> - Support building both the static libraries and dynamic libraries > >> using the same set of .o files, instead of separately compiled .o > >> files. That helps improve build speed and reduce memory overhead for > >> building JDK. Your current refactoring work aims to help that. > >> - Clean up the usages of STATIC_BUILD macro. Most of the usages are in > >> test code. > >> - Other runtime fixes/enhancements in the leyden > >> https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch > >> > >> I think most work mentioned in III has dependencies on II. We need a > >> workable base to be able to build the "fully" statically linked > >> launcher for building and testing the work mentioned in III, when > >> integrating any of those to the JDK mainline. The makefile refactoring > >> work can be done in parallel but does not need to be completed before > >> we add the static linking step in JDK mainline. > >> > >>> 2. Additional runtime fixes/enhancements on top of the existing static support in JDK, e.g. support further lookup dynamic native library if the built-in native library cannot be found. > >>> > >>> 3. Some initial (prototype) work on supporting hermetic JDK resource files in the jimage (JDK modules image). > >>> > >>> To move forward, one of the earliest items needed is to add the capability of building the fully statically linked Java launcher in JDK mainline. The other static Java runtime changes can be followed up after the launcher linking part, so they can be built and tested as individual PRs created for the JDK mainline. Magnus, you have expressed interest in helping get the launcher linking part (refactor from https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk) into JDK mainline. What's your thought on prioritizing the launcher static linking part before other makefile clean ups for static libraries? > >>> > >>> Trust me, my absolute top priority now is working on getting the proper build support needed for Hermetic Java. I can't prioritize it any higher. > >> Thanks! > >> > >>> I am not sure what you are asking for. We can't just merge StaticLink.gmk from your prototype. And even if we did, what good will it do you? > >> Please see my comments above. > >> > >>> The problem you are running into is that the build system has not been designed to properly support static linking. There are already 3-4 hacks in place to get something sort-of useful out, but they are prone to breaking. I assume that we agree that for Hermetic Java to become a success, we need to have a stable foundation for static builds. > >>> > >>> The core problem of all static linking hacks is that they are not integrated in the right place. They need to be a core part of what NativeCompilation delivers, not something done in a separate file. To put it in other words, StaticLink.gmk from your branch do not need cleanup -- it needs to go away, and the functionality moved to the proper place. > >>> > >>> My approach is that NativeCompilation should support doing either only dynamic linking (as today), or static linking (as today with STATIC_LIBS or STATIC_BUILD), or both. The assumption is that the latter will be default, or at least should be tested by default in GHA. For this to work, we need to compile the source code to .o files only once, and then link these .o files either into a dynamic or a static library (or both). > >> As of today, the leyden > >> https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch > >> can build a "fully" statically linked Java launcher. The issue of > >> compiling the dynamic and static libraries .o files separately is not > >> a blocker. It's good to have it resolved at some point of time. > >> > >>> This, in turn, require several changes: > >>> > >>> 1) The linking code needs to be cleaned up, and all technical debt needs to be resolved. This is what I have been doing since I started working on static builds for Hermetic Java. JDK-8329704 (which was integrated yesterday) was the first major milestone of this cleanup. Now, the path were to find a library created by the JDK (static or dynamic) is encapsulated in ResolveLibPath. This is currently a monster, but at least all knowledge is collected in a single location, instead of spread over the code base. Getting this simplified is the next step. > >>> > >>> 2) We need to stop passing the STATIC_BUILD define when compiling. This is partially addressed in your PR, where you have replaced #ifdef STATIC_BUILD with a dynamic lookup. But there is also the problem of JNI/JVMTI entry points. I have been pondering how we can compile the code in a way so we support both dynamic and static name resolution, and I think I have a solution. > >>> > >>> This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. > >> Thumbs up! That seems to be a good direction. Currently in the leyden > >> branch, it first looks up the unique > >> JNI_OnLoad<_lib_name>|Agent_OnLoad<_lib_name> etc for built-in > >> libraries, then search for the dynamic libraries using the > >> conventional naming when necessary. e.g.: > >> > >> https://github.com/openjdk/leyden/commit/a5c886d2e85a0ff0c3712a5488ae61d8c9d7ba1a > >> https://github.com/openjdk/leyden/commit/1da8e3240e0bd27366d19f2e7dde386e46015135 > >> > >> When spec supports JNI_OnLoad_ and etc. for dynamic > >> libraries, we may still need to support the conventional naming > >> without the <_lib_name> part for existing libraries out there. > >> > >>> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. > >>> > >>> A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. > >> Thank you for taking this on! Potentially we could consider taking the > >> objcopy to localizing hotspot symbols on unix-like platforms, based on > >> https://github.com/openjdk/jdk/pull/17456 discussions. Additional > >> testing is still needed to verify the solution. > >> > >>> My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. > >> Most of the JDK resources are now supported as hermetic jimage > >> (lib/modules) bundled in the > >> https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch. > >> The remaining sound.properties, ct.sym and .jfc files can be handled > >> later. Overally, that part of the work has confirmed the hermetic > >> jimage bundled solution is robust and helps resolve some of the > >> difficult start-up sequence issues observed when the hermetic resource > >> was implemented using JAR file based solution. > >> > >> It might be a good idea to follow up on the static linking discussion > >> in tomorrow's zoom meeting (hope you'll be able to join tomorrow). > >> > >> Thanks! > >> > >> Jiangli > >>> /Magnus > >>> > >>> > >>> > >>> Thanks! > >>> Jiangli > >>> > >>> On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: > >>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: > >>>>> Hi Magnus, > >>>>> > >>>>> Thanks for looking into this from the build perspective. > >>>>> > >>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie > >>>>> wrote: > >>>>>> 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. > >>>>> Some additional hermetic Java related references that are also useful: > >>>>> > >>>>> - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that > >>>>> links to the issues for resolving static linking issues so far > >>>>> - https://github.com/openjdk/jdk21/pull/26 is the enhancement for > >>>>> building the complete set of static libraries in JDK/VM, particularly > >>>>> including libjvm.a > >>>>> > >>>>>> 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? > >>>>> I have a similar view as Alan responded in your other email thread. > >>>>> Things are still in the early stage for the general solution. > >>>>> > >>>>> In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime > >>>>> branch, when configuring JDK with --with-static-java=yes, the JDK > >>>>> binary contains the following extra artifacts: > >>>>> > >>>>> - static-libs/*.a: The complete set of JDK/VM static libraries > >>>>> - jdk/bin/javastatic: A demo Java launcher fully statically linked > >>>>> with the selected JDK .a libraries (e.g. it currently statically link > >>>>> with the headless) and libjvm.a. It's the standard Java launcher > >>>>> without additional work for hermetic Java. > >>>>> > >>>>> In our prototype for hermetic Java, we build the hermetic executable > >>>>> image (a single image) from the following input (see description on > >>>>> singlejar packaging tool in > >>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf): > >>>>> > >>>>> - A customized launcher (with additional work for hermetic) executable > >>>>> fully statically linked with JDK/VM static libraries (.a files), > >>>>> application natives and dependencies (e.g. in .a static libraries) > >>>>> - JDK lib/modules, JDK resource files > >>>>> - Application classes and resource files > >>>>> > >>>>> Including a JDK library .a into the corresponding .jmod would require > >>>>> extracting the .a for linking with the executable. In some systems > >>>>> that may cause memory overhead due to the extracted copy of the .a > >>>>> files. I think we should consider the memory overhead issue. > >>>>> > >>>>> One possibility (as Alan described in his response) is for jlink to > >>>>> invoke the ld on the build system. jlink could pass the needed JDK > >>>>> static libraries and libjvm.a (provided as part of the JDK binary) to > >>>>> ld based on the modules required for the application. > >>>>> > >>>> I gave a bit more thoughts on this one. For jlink to trigger ld, it > >>>> would need to know the complete linker options and inputs. Those > >>>> include options and inputs related to the application part as well. In > >>>> some usages, it might be easier to handle native linking separately > >>>> and pass the linker output, the executable to jlink directly. Maybe we > >>>> could consider supporting different modes for various usages > >>>> requirements, from static libraries and native linking point of view: > >>>> > >>>> Mode #1 > >>>> Support .jmod packaged natives static libraries, for both JDK/VM .a > >>>> and application natives and dependencies. If the inputs to jlink > >>>> include .jmods, jlink can extract the .a libraries and pass the > >>>> information to ld to link the executable. > >>>> > >>>> Mode #2 > >>>> Support separate .a as jlink input. Jlink could pass the path > >>>> information to the .a libraries and other linker options to ld to > >>>> create the executable. > >>>> > >>>> For both mode #1 and #2, jlink would then use the linker output > >>>> executable to create the final hermetic image. > >>>> > >>>> Mode #3 > >>>> Support a fully linked executable as a jlink input. When a linked > >>>> executable is given to jlink, it can process it directly with other > >>>> JDK data/files to create the final image, without native linking step. > >>>> > >>>> Any other thoughts and considerations? > >>>> > >>>> Best, > >>>> Jiangli > >>>> > >>>>>> 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. > >>>>> An alternative with less memory overhead could be using application > >>>>> modular JAR and separate .a as the input for jlink. > >>>>> > >>>>>> 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. > >>>>> Part of the current effort includes resolving the discovered symbol > >>>>> collision issues with static linking. Will respond to your other email > >>>>> on the symbol issue separately later. > >>>>> > >>>>>> 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. > >>>>> I think we would need both configure flag and special target for the > >>>>> static builds. > >>>>> > >>>>>> 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. > >>>>> For the potential objcopy work to resolve symbol issues, we can add > >>>>> that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We > >>>>> have an internal prototype (not included in > >>>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done > >>>>> by one of colleagues for localizing symbols in libfreetype using > >>>>> objcopy. > >>>>> > >>>>>> 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". > >>>>> If we want to also build a fully statically linked launcher, maybe > >>>>> --with-static-java? Being able to configure either dynamic, static or > >>>>> both as you suggested also seems to be a good idea. > >>>>> > >>>>>> 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. > >>>>> Completely agree. It would be good to avoid recompiling the .o file > >>>>> for static and dynamic builds. As proposed in > >>>>> https://bugs.openjdk.org/browse/JDK-8303796: > >>>>> > >>>>> It's beneficial to be able to build both .so and .a from the same set > >>>>> of .o files. That would involve some changes to handle the dynamic JDK > >>>>> and static JDK difference at runtime, instead of relying on the > >>>>> STATIC_BUILD macro. > >>>>> > >>>>>> 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. > >>>>> Renaming or redefining the symbol at build time could cause confusions > >>>>> with debugging. That's a concern raised in > >>>>> https://github.com/openjdk/jdk/pull/17456 discussions. > >>>>> > >>>>> Additionally, redefining symbols using tools like objcopy may not > >>>>> handle member names referenced in string literals. For example, in > >>>>> https://github.com/openjdk/jdk/pull/17456 additional changes are > >>>>> needed in assembling and SA to reflect the symbol change. > >>>>> > >>>>>> 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? > >>>>> We have done some testing with jtreg SA related tests for the fully > >>>>> statically linked `javastatic`. > >>>>> > >>>>> If we use objcopy to localize symbols in hotspot, it's not yet clear > >>>>> what's the impact on SA. We could do some tests. The other question > >>>>> that I raised is the supported gcc versions (for partial linking) > >>>>> related to the solution. > >>>>> > >>>>> Best, > >>>>> Jiangli > >>>>> > >>>>>> /Magnus > >>>>>> From magnus.ihse.bursie at oracle.com Tue Apr 16 18:27:08 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 16 Apr 2024 20:27:08 +0200 Subject: Hermetic Java project meeting Message-ID: This is my summary of what was said in today's meeting: * Jiangli reported that her team had done extensive testing and not seen any problems, both with just the static launcher as generated by the leyden branch, and with bundled user applications using the One Jar (?) tool. They tested JDK tier 1, and an suite of Google's internal tests. When testing JTReg tests with native libraries, these were dynamically loaded. * Alan asked about Hotspot JTReg tests that launched "java". Jiangli reported that they had not seen any problems, but my understanding was that there was some confusion if any such tests were actually run. I think this is something that will need further attention, but if someone said they would look into it, I missed it. ?* Jiangli will get numbers on how much time is added to the GHA testing if we add building and linking of static libraries, without fixing so we can compile to a single set of object files. * We did not fully come to a conclusion if compiling on a single set of object files for static and dynamic linking was a hard requirement or not, but at a minimum it is a desirable goal. (My personal opinion is that is a hard requirement if the GHA build times are seriously affected otherwise.) There are basically two problems prohibiting single object file compilation: 1) using dynamic checks instead of #ifdefs for code that differs between static and dynamic. 2) Handling the difference between JNI_OnLoad (as required for dynamic libraries) and JNI_OnLoad_ (as required for static libraries). * The leyden branch has basically solved both these problems. The first one could more or less be integrated already (given perhaps some discussion on exactly *how* the JDK should discover in runtime if it is static or dynamic), but the latter requires a spec change to be integrated. * I think everyone agreed that moving on with a spec change was a good idea, regardless of if this is blocker or not, but I don't recall that there were any concrete next steps decided. Ron and Alan said that we do spec changes all the time so it will not add as much bureaucracy as one might fear. * Regarding which native libraries to include, I think we agreed on the following: ? - Static linking will only support headless-only builds (in which the build system excludes the AWT library that does "headful" stuff -- otherwise there would be duplicate symbols) ? - As a first delivery, the build system will just create a static version of the "java" launcher (not jar, javac, etc). This will include all native libraries from all modules that are included in the build. ? - Going forward, the correct solution is to make jlink create a launcher that includes just the native libraries from the modules that is included in the jlink command. This will require jlink to understand how to call the native linker. ? - Somewhere in there we probably also needs to have jlink know about headless-only vs normal (headless or "headful" determined on runtime), so it can create a java.desktop output that includes only the headless library. * Magnus reported that the refactoring and fixing of technical debt that was required for doing static builds properly has just been finished, and that his attention is now turning into creating a properly integrated system for generating static builds alongside dynamic builds. * Jiangli and Magnus will work outside the meeting to resolve the build issues Magnus faced with the hermetic java branch in the Leyden repo. * Just before the meeting unfortunately had to be aborted, Jiangli mentioned that they had discovered issues with some JDK native libraries when using objcopy to localize all non-visible symbols. It was at the time of writing not clear what those issues were. Jiangli will report back with what they found. (And while I had not time to mention it on the meeting, I will also look into this.) /Magnus From jianglizhou at google.com Tue Apr 16 19:39:28 2024 From: jianglizhou at google.com (Jiangli Zhou) Date: Tue, 16 Apr 2024 12:39:28 -0700 Subject: Hermetic Java project meeting In-Reply-To: References: Message-ID: Magnus, thanks for the meeting summary! Please see clarifications below, to avoid any confusion. On Tue, Apr 16, 2024 at 11:27?AM Magnus Ihse Bursie wrote: > > This is my summary of what was said in today's meeting: > > * Jiangli reported that her team had done extensive testing and not seen > any problems, both with just the static launcher as generated by the > leyden branch, and with bundled user applications using the One Jar (?) > tool. They tested JDK tier 1, and an suite of Google's internal tests. > When testing JTReg tests with native libraries, these were dynamically > loaded. Clarifications, as discussed in the meeting: We have done multiple levels of testing for static/hermetic Java prototype with our internal codebase on JDK 11, JDK 21 and JDK head (mainline based). We run into bugs/failures and have addressed the issues found along the way. The layden branch contains most of the static/hermetic Java work from the prototype. In general static/hermetic Java support looks robust in current state on JDK 21 in our prototype based on testing (already communicated some of the the testing outcome on JDK 11 in last years JVMLS), with some of the remaining areas (e.g. how to handle user code accessing java.home, and https://github.com/openjdk/leyden/blob/hermetic-java-runtime/src/java.base/share/classes/jdk/internal/misc/JavaHome.java is still a internal class in the prototpye) that require broad discussions involving potential spec updates, and a small number of remaining failures to be looked into. Testing we have done includes: - jtreg with tier1 using `javastatic` ("fully" statically linked Java launcher) on JDK 11 and JDK 21 - Explicit functional and integration tests (most of them are developed base on existing jtreg tests) to test the final hermetic Java image. Image is built using singlejar, and the test and JDK are in a single image. - Scattered hermetic Java testing using our internal tests. The scattered hermetic image is a special mode for testing to emulate hermetic Java image execution without building the final hermetic Java. This requires some additional launcher changes that are not in the lenden branch currently. - Some production testing on JDK 11 and JDK 21 > > * Alan asked about Hotspot JTReg tests that launched "java". Jiangli > reported that they had not seen any problems, Also clarification: As mentioned during the meeting, most of the issues that we found with jtreg tier1 testing were due to the assumption of using dynamic libraries in the tests. We have addressed those. Alan had some questions about launching sub-processes. In the prototype, we had done work to support POSIX_SPAWN launch mechanism for ProcessBuilder.start() on hermetic Java, e.g. https://github.com/openjdk/leyden/commit/931b71b0845d24b1949a23333ef1cdb3d6622596. We need to look into tier1 testing to verify if they cover sub-processing testing (Alan mentioned there are some in tier1). > but my understanding was > that there was some confusion if any such tests were actually run. I > think this is something that will need further attention, but if someone > said they would look into it, I missed it. Megnas, can you please elaborate the above about "if any such tests were actually run"? > > * Jiangli will get numbers on how much time is added to the GHA > testing if we add building and linking of static libraries, without > fixing so we can compile to a single set of object files. Will follow up on this. > > * We did not fully come to a conclusion if compiling on a single set of > object files for static and dynamic linking was a hard requirement or > not, but at a minimum it is a desirable goal. (My personal opinion is > that is a hard requirement if the GHA build times are seriously affected > otherwise.) > > There are basically two problems prohibiting single object file > compilation: > > 1) using dynamic checks instead of #ifdefs for code that differs between > static and dynamic. > > 2) Handling the difference between JNI_OnLoad (as required for dynamic > libraries) and JNI_OnLoad_ (as required for static libraries). > > * The leyden branch has basically solved both these problems. The first > one could more or less be integrated already (given perhaps some > discussion on exactly *how* the JDK should discover in runtime if it is > static or dynamic), but the latter requires a spec change to be integrated. > > * I think everyone agreed that moving on with a spec change was a good > idea, regardless of if this is blocker or not, but I don't recall that > there were any concrete next steps decided. Ron and Alan said that we do > spec changes all the time so it will not add as much bureaucracy as one > might fear. There was also a question raised by Dave during the meeting on the timeline for the spec/JSR related work. > > * Regarding which native libraries to include, I think we agreed on the > following: > - Static linking will only support headless-only builds (in which the > build system excludes the AWT library that does "headful" stuff -- > otherwise there would be duplicate symbols) Yes. > - As a first delivery, the build system will just create a static > version of the "java" launcher (not jar, javac, etc). This will include > all native libraries from all modules that are included in the build. Yes. It would be headless based. > - Going forward, the correct solution is to make jlink create a > launcher that includes just the native libraries from the modules that > is included in the jlink command. This will require jlink to understand > how to call the native linker. Yes. That would be one of the N-step for supporting hermetic Java. > - Somewhere in there we probably also needs to have jlink know about > headless-only vs normal (headless or "headful" determined on runtime), > so it can create a java.desktop output that includes only the headless > library. Alan has described an idea of dealing with java.desktop using jlink. > > * Magnus reported that the refactoring and fixing of technical debt that > was required for doing static builds properly has just been finished, > and that his attention is now turning into creating a properly > integrated system for generating static builds alongside dynamic builds. Thank you, Magnus! > > * Jiangli and Magnus will work outside the meeting to resolve the build > issues Magnus faced with the hermetic java branch in the Leyden repo. Yes. > > * Just before the meeting unfortunately had to be aborted, Jiangli > mentioned that they had discovered issues with some JDK native libraries > when using objcopy to localize all non-visible symbols. It was at the > time of writing not clear what those issues were. Jiangli will report > back with what they found. (And while I had not time to mention it on > the meeting, I will also look into this.) Best, Jiangli > > /Magnus > From jianglizhou at google.com Tue Apr 16 21:28:58 2024 From: jianglizhou at google.com (Jiangli Zhou) Date: Tue, 16 Apr 2024 14:28:58 -0700 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <8852ba23-2830-4d23-ae52-11c554d8d750@oracle.com> Message-ID: On Tue, Apr 16, 2024 at 9:20?AM Jiangli Zhou wrote: > > On Tue, Apr 16, 2024 at 8:30?AM Magnus Ihse Bursie > wrote: > > > > Jiangli, > > > > First of all: I tried building the leyden branch "hermetic-java-runtime" but failed. :-( I tried some various attempts to work around the failures, but the javastatic file I ended up with were unable to start. > > Magnus, I recall you mentioned that you had build issues during one of > the zoom meetings earlier this year (didn't hear any follow-up on it). > Let's get this resolved for you first. Can you please share the build > failures/errors and runtime errors that you run into? > > Same questions about your build environment, as you asked below. > > > > > What kind of environment are you using to build this branch? (OS, compiler, libc version, etc) Do you have any special configure flags that are required? > > For the leyden hermetic-java-runtime branch, I've only been building > on Linux. I've used both gcc and clang. > > Yes, the branch requires `--with-static-java=yes`, e.g. > > bash configure --with-boot-jdk= > --with-debug-level=slowdebug --with-static-java=yes > > I documented the build information in one of the comment messages. > That's probably not the best place. I'll look for a better place. > > Let's discuss more on the rest of the topics below during our meeting > today. We can update on the mailing list about the discussion, if > others are interested. For anyone who's interested in the topics, https://mail.openjdk.org/pipermail/leyden-dev/2024-April/000643.html is a separate email thread with today's meeting summary from @Magnus Ihse Bursie and responses from me. Best, Jiangli > > Best, > Jiangli > > > > > I would very much like to test it out myself to check this static java launcher that you are creating. > > > > On 2024-04-16 03:01, Jiangli Zhou wrote: > > > > The main purpose of StaticLink.gmk is to support the static-java-image > > make target, which can be used to perform the actual static linking > > step using libjvm.a and JDK static libraries. That currently doesn't > > exist in the JDK mainline. Creating a "fully" statically linked Java > > launcher is the first step (out of many) towards supporting > > static/hermetic Java. > > > > I am still not sure it is the best design to have this in a separate file. You are in some way "just" creating a new launcher. > > > > As part of cleaning/refactoring/integrating for the static linking > > step, we want to agree and decide/accept on the following: > > > > - Support the "fully" statically linked java launcher for testing and > > demoing the capability of static JDK support, e.g. > > - Support running jtreg testing using the "fully" statically linked > > Java launcher > > > > So how do you want to test native jtreg tests? By compiling the jtreg tests to native .a files and statically link with those as well, or to make this a hybrid mode where a statically linked launcher loads the jtreg tests dynamically? > > > > - Set up tests in github workflow to help detect any breaking > > changes for static support, e.g. new symbol issues introduced by any > > changes. There were some earlier discussions on this with Ron and Alan > > during the zoom meetings. > > > > If we do this correct, we should not have to worry about symbol conflicts. (Local symbols should all be hidden before creation of the static libraries.) That said, creating static libraries needs to be regularly tested or it will break. > > > > - Which JDK native libraries to be statically linked with the new > > launcher target? E.g. StaticLink.gmk currently excludes libjsound.a, > > libawt_xawt.a, etc from statically linked with the launcher. > > > > That sounds rather arbitrarily. I would assume that a statically linked launcher should include native libraries from all included modules. If you are not interested in java.desktop native libraries, then you'd need to exclude java.desktop from the build. But my assumption here is that we need to build a solution that works with all modules included in the JDK, and that is what must be tested in GHA. > > > > - Do we want more than one statically linked launcher target, based on > > the set of linked native libraries? > > > > Do you mean that you want like "static-java-java.base-only", "static-java-eveything-but-java.desktop" etc? That does not sound like something that belongs in the makefiles. If you want to build a JDK that can only support a certain subset of modules, you need to specify those module in your build scripts as input to configure. > > > > (II) What missing: > > - Static linking step as mentioned above > > > > (III) What needs to be improved (require cleanups and refactoring, and > > you mentioned some of those in your response as well): > > - Support building both the static libraries and dynamic libraries > > using the same set of .o files, instead of separately compiled .o > > files. That helps improve build speed and reduce memory overhead for > > building JDK. Your current refactoring work aims to help that. > > - Clean up the usages of STATIC_BUILD macro. Most of the usages are in > > test code. > > - Other runtime fixes/enhancements in the leyden > > https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch > > > > I think most work mentioned in III has dependencies on II. We need a > > workable base to be able to build the "fully" statically linked > > launcher for building and testing the work mentioned in III, when > > integrating any of those to the JDK mainline. The makefile refactoring > > work can be done in parallel but does not need to be completed before > > we add the static linking step in JDK mainline. > > > > I'm not sure I understand why you consider (II) to be a prerequisite for the (III) issues. From my point of view, they are all mutually independent changes that needs to be done, and if anything, I think getting in code to create a statically linked launcher will probably be easier if we get further along on the other issues. > > > > In particular, I'd like to see changes to the STATIC_BUILD macro come in first. Ideally, we should not send in such a macro at all. The JNI_OnLoad stuff is bugging me mostly. > > > > As of today, the leyden > > https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch > > can build a "fully" statically linked Java launcher. The issue of > > compiling the dynamic and static libraries .o files separately is not > > a blocker. It's good to have it resolved at some point of time. > > > > Weeeell, yes and no... It is not *technically* a blocker, but unless we can reuse the .o files, including static builds in the standard testing on GHA will effectively double the build time, and that is definitely not acceptable. And the alternative is to bring in static builds without having it regularly tested, which I don't think is acceptable either. > > > > So the conclusion is that getting static and dynamic libraries built from the same .o files is in effect a blocker for Hermetic Java. > > > > This, in turn, require several changes: > > > > 1) The linking code needs to be cleaned up, and all technical debt needs to be resolved. This is what I have been doing since I started working on static builds for Hermetic Java. JDK-8329704 (which was integrated yesterday) was the first major milestone of this cleanup. Now, the path were to find a library created by the JDK (static or dynamic) is encapsulated in ResolveLibPath. This is currently a monster, but at least all knowledge is collected in a single location, instead of spread over the code base. Getting this simplified is the next step. > > > > 2) We need to stop passing the STATIC_BUILD define when compiling. This is partially addressed in your PR, where you have replaced #ifdef STATIC_BUILD with a dynamic lookup. But there is also the problem of JNI/JVMTI entry points. I have been pondering how we can compile the code in a way so we support both dynamic and static name resolution, and I think I have a solution. > > > > This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. > > > > Thumbs up! That seems to be a good direction. Currently in the leyden > > branch, it first looks up the unique > > JNI_OnLoad<_lib_name>|Agent_OnLoad<_lib_name> etc for built-in > > libraries, then search for the dynamic libraries using the > > conventional naming when necessary. e.g.: > > > > https://github.com/openjdk/leyden/commit/a5c886d2e85a0ff0c3712a5488ae61d8c9d7ba1a > > https://github.com/openjdk/leyden/commit/1da8e3240e0bd27366d19f2e7dde386e46015135 > > > > When spec supports JNI_OnLoad_ and etc. for dynamic > > libraries, we may still need to support the conventional naming > > without the <_lib_name> part for existing libraries out there. > > > > That looks interesting. Basically, this is very similar to what I imagine needs to be done in the mainline. However, I don't think we can just change this code like that without a CSR? Or are we allowed to treat JDK-internal libraries different than the specification states? > > > > I would say getting this part into mainline should be the main focus right now, not the StaticLink.gmk file. And that includes getting any CSR approvals etc. > > > > Thank you for taking this on! Potentially we could consider taking the > > objcopy to localizing hotspot symbols on unix-like platforms, based on > > https://github.com/openjdk/jdk/pull/17456 discussions. Additional > > testing is still needed to verify the solution. > > > > We don't need any additional testing on that; proof of concept shows it works. It just needs to be implemented. With JDK-8330261 (pushed today), the ground is now prepared to get it done. It is next on my todo-list. > > > > It might be a good idea to follow up on the static linking discussion > > in tomorrow's zoom meeting (hope you'll be able to join tomorrow). > > > > I'll join but might be somewhat late due to family commitments. > > > > /Magnus From jianglizhou at google.com Tue Apr 16 22:44:17 2024 From: jianglizhou at google.com (Jiangli Zhou) Date: Tue, 16 Apr 2024 15:44:17 -0700 Subject: Hermetic Java project meeting In-Reply-To: References: Message-ID: On Tue, Apr 16, 2024 at 12:39?PM Jiangli Zhou wrote: > > Magnus, thanks for the meeting summary! Please see clarifications > below, to avoid any confusion. > > On Tue, Apr 16, 2024 at 11:27?AM Magnus Ihse Bursie > wrote: > > > > This is my summary of what was said in today's meeting: > > > > * Jiangli reported that her team had done extensive testing and not seen > > any problems, both with just the static launcher as generated by the > > leyden branch, and with bundled user applications using the One Jar (?) > > tool. They tested JDK tier 1, and an suite of Google's internal tests. > > When testing JTReg tests with native libraries, these were dynamically > > loaded. > > Clarifications, as discussed in the meeting: > > We have done multiple levels of testing for static/hermetic Java > prototype with our internal codebase on JDK 11, JDK 21 and JDK head > (mainline based). We run into bugs/failures and have addressed the > issues found along the way. The layden branch contains most of the > static/hermetic Java work from the prototype. In general > static/hermetic Java support looks robust in current state on JDK 21 > in our prototype based on testing (already communicated some of the > the testing outcome on JDK 11 in last years JVMLS), with some of the > remaining areas (e.g. how to handle user code accessing java.home, and > https://github.com/openjdk/leyden/blob/hermetic-java-runtime/src/java.base/share/classes/jdk/internal/misc/JavaHome.java > is still a internal class in the prototpye) that require broad > discussions involving potential spec updates, and a small number of > remaining failures to be looked into. > > Testing we have done includes: > - jtreg with tier1 using `javastatic` ("fully" statically linked Java > launcher) on JDK 11 and JDK 21 > - Explicit functional and integration tests (most of them are > developed base on existing jtreg tests) to test the final hermetic > Java image. Image is built using singlejar, and the test and JDK are > in a single image. > - Scattered hermetic Java testing using our internal tests. The > scattered hermetic image is a special mode for testing to emulate > hermetic Java image execution without building the final hermetic > Java. This requires some additional launcher changes that are not in > the lenden branch currently. > - Some production testing on JDK 11 and JDK 21 > > > > > * Alan asked about Hotspot JTReg tests that launched "java". Jiangli > > reported that they had not seen any problems, > > Also clarification: > > As mentioned during the meeting, most of the issues that we found with > jtreg tier1 testing were due to the assumption of using dynamic > libraries in the tests. We have addressed those. > > Alan had some questions about launching sub-processes. In the > prototype, we had done work to support POSIX_SPAWN launch mechanism > for ProcessBuilder.start() on hermetic Java, e.g. > https://github.com/openjdk/leyden/commit/931b71b0845d24b1949a23333ef1cdb3d6622596. > We need to look into tier1 testing to verify if they cover > sub-processing testing (Alan mentioned there are some in tier1). > > > but my understanding was > > that there was some confusion if any such tests were actually run. I > > think this is something that will need further attention, but if someone > > said they would look into it, I missed it. > > Megnas, can you please elaborate the above about "if any such tests > were actually run"? > > > > > * Jiangli will get numbers on how much time is added to the GHA > > testing if we add building and linking of static libraries, without > > fixing so we can compile to a single set of object files. > > Will follow up on this. I did some measurements using the https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch on my Linux desktop today. Here's the detail: - Build machine: Debian 6.6.* - gcc version 13.2.0 - `Time` command is used to do the measurements - Same configuration is used: --with-boot-jdk= --with-debug-level=slowdebug --with-static-java=yes - `make clean` is done before both of the measurements # # Building JDK image with just dynamic libraries # Build command: make images # real 5m27.582s user 75m11.272s sys 8m2.783s # # Building JDK image with both dynamic libraries and static libraries, also link bin/javastatic # Build command: make static-java-image # real 6m5.958s user 115m59.353s sys 15m11.664s There is some overhead with the overall build time, but it's not as significant as doubling the time. I think we should consider prioritizing the launcher static linking work for now. I also want to reiterate the importance of compiling just the .o files only once and use them for both the dynamic libraries and static libraries. In our prototype on JDK 11, we did that. When moving the work to JDK head for the leyden branch and mainline, we adopted to use the existing `static-libs-image` for building the full set of static libraries with separately compiled .o files (https://bugs.openjdk.org/browse/JDK-8307858). As mentioned in some of the earlier meetings with Alan and Ron last year, we ran into memory issues during JDK build time on our system due to the duplication of the .o files. I did some workaround to mitigate the memory issue. So we should also prioritize the work although it is a non-blocker for integrating some of the leyden branch work into the mainline at this point. I'd recommend addressing that immediately after the launcher static linking work. As you are already aware of, it would require some of the runtime work to clean up the STATIC_BUILD macro usages. Best, Jiangli > > > > > * We did not fully come to a conclusion if compiling on a single set of > > object files for static and dynamic linking was a hard requirement or > > not, but at a minimum it is a desirable goal. (My personal opinion is > > that is a hard requirement if the GHA build times are seriously affected > > otherwise.) > > > > There are basically two problems prohibiting single object file > > compilation: > > > > 1) using dynamic checks instead of #ifdefs for code that differs between > > static and dynamic. > > > > 2) Handling the difference between JNI_OnLoad (as required for dynamic > > libraries) and JNI_OnLoad_ (as required for static libraries). > > > > * The leyden branch has basically solved both these problems. The first > > one could more or less be integrated already (given perhaps some > > discussion on exactly *how* the JDK should discover in runtime if it is > > static or dynamic), but the latter requires a spec change to be integrated. > > > > * I think everyone agreed that moving on with a spec change was a good > > idea, regardless of if this is blocker or not, but I don't recall that > > there were any concrete next steps decided. Ron and Alan said that we do > > spec changes all the time so it will not add as much bureaucracy as one > > might fear. > > There was also a question raised by Dave during the meeting on the > timeline for the spec/JSR related work. > > > > > * Regarding which native libraries to include, I think we agreed on the > > following: > > - Static linking will only support headless-only builds (in which the > > build system excludes the AWT library that does "headful" stuff -- > > otherwise there would be duplicate symbols) > > Yes. > > > - As a first delivery, the build system will just create a static > > version of the "java" launcher (not jar, javac, etc). This will include > > all native libraries from all modules that are included in the build. > > Yes. It would be headless based. > > > - Going forward, the correct solution is to make jlink create a > > launcher that includes just the native libraries from the modules that > > is included in the jlink command. This will require jlink to understand > > how to call the native linker. > > Yes. That would be one of the N-step for supporting hermetic Java. > > > - Somewhere in there we probably also needs to have jlink know about > > headless-only vs normal (headless or "headful" determined on runtime), > > so it can create a java.desktop output that includes only the headless > > library. > > Alan has described an idea of dealing with java.desktop using jlink. > > > > > * Magnus reported that the refactoring and fixing of technical debt that > > was required for doing static builds properly has just been finished, > > and that his attention is now turning into creating a properly > > integrated system for generating static builds alongside dynamic builds. > > Thank you, Magnus! > > > > > * Jiangli and Magnus will work outside the meeting to resolve the build > > issues Magnus faced with the hermetic java branch in the Leyden repo. > > Yes. > > > > > * Just before the meeting unfortunately had to be aborted, Jiangli > > mentioned that they had discovered issues with some JDK native libraries > > when using objcopy to localize all non-visible symbols. It was at the > > time of writing not clear what those issues were. Jiangli will report > > back with what they found. (And while I had not time to mention it on > > the meeting, I will also look into this.) > > Best, > Jiangli > > > > > /Magnus > > From duke at openjdk.org Wed Apr 17 04:21:30 2024 From: duke at openjdk.org (duke) Date: Wed, 17 Apr 2024 04:21:30 GMT Subject: git: openjdk/leyden: premain: 153 new changesets Message-ID: Changeset: d80d4781 Author: Archie Cobbs Committer: Vicente Romero Date: 2024-04-04 21:13:49 +0000 URL: https://git.openjdk.org/leyden/commit/d80d4781828d68c498831cddf9782055dda472d1 8328649: Disallow enclosing instances for local classes in constructor prologues Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java + test/langtools/tools/javac/LocalClassCtorPrologue.java + test/langtools/tools/javac/LocalClassCtorPrologue.out ! test/langtools/tools/javac/SuperInit/SuperInitGood.java Changeset: 12ad09a9 Author: Alex Menkov Date: 2024-04-04 21:30:50 +0000 URL: https://git.openjdk.org/leyden/commit/12ad09a966030e7ed0900e205df4b412cf0b6a32 8322042: HeapDumper should perform merge on the current thread instead of VMThread Reviewed-by: sspitsyn, kevinw ! src/hotspot/share/runtime/vmOperation.hpp ! src/hotspot/share/services/heapDumper.cpp Changeset: e1183ac0 Author: Mikael Vidstedt Date: 2024-04-04 21:32:51 +0000 URL: https://git.openjdk.org/leyden/commit/e1183ac044f803bf0d4ccfebc2b1cd5b33294c7a 8329703: Remove unused apple.jpeg file from SwingSet2 demo Reviewed-by: prr - src/demo/share/jfc/SwingSet2/resources/images/food/apple.jpeg Changeset: 27cfcef9 Author: David Holmes Date: 2024-04-05 00:29:06 +0000 URL: https://git.openjdk.org/leyden/commit/27cfcef99f1acae1ba0beb49d01acbc47154a54b 8329651: TestLibGraal.java crashes with assert(_stack_base != nullptr) Reviewed-by: stefank, dcubed ! src/hotspot/share/runtime/thread.cpp Changeset: 34f7974a Author: David Holmes Date: 2024-04-05 01:10:03 +0000 URL: https://git.openjdk.org/leyden/commit/34f7974a40850f89b022a6254beab72f7811c85e 8325303: Replace markWord.is_neutral() with markWord.is_unlocked() Reviewed-by: stefank, dcubed ! src/hotspot/share/oops/markWord.cpp ! src/hotspot/share/oops/markWord.hpp ! src/hotspot/share/runtime/basicLock.cpp ! src/hotspot/share/runtime/basicLock.hpp ! src/hotspot/share/runtime/synchronizer.cpp Changeset: 0b01144e Author: David Holmes Date: 2024-04-05 02:15:48 +0000 URL: https://git.openjdk.org/leyden/commit/0b01144ecec1283adaaaf1a7f53d075a56f030ae 8329720: Gtest failure printing markword after JDK-8325303 Reviewed-by: mikael ! test/hotspot/gtest/oops/test_markWord.cpp Changeset: 5860a48c Author: Joe Darcy Date: 2024-04-05 05:04:48 +0000 URL: https://git.openjdk.org/leyden/commit/5860a48c71e324f77a7ecc613c063cbb81580011 8329624: Add visitors for preview language features Reviewed-by: vromero, jlahoda ! src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java ! src/java.compiler/share/classes/javax/annotation/processing/ProcessingEnvironment.java + src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java + src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitorPreview.java + src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitorPreview.java + src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java + src/java.compiler/share/classes/javax/lang/model/util/ElementScannerPreview.java + src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitorPreview.java + src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java + src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitorPreview.java + src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitorPreview.java ! test/langtools/tools/javac/lib/JavacTestingAbstractProcessor.java Changeset: c1cfb43d Author: Richard Reingruber Date: 2024-04-05 06:27:08 +0000 URL: https://git.openjdk.org/leyden/commit/c1cfb43d8de8d0eed01b9bb6aa1202dc7cbff007 8329109: Threads::print_on() tries to print CPU time for terminated GC threads Reviewed-by: mbaesken, dholmes, ayang ! src/hotspot/share/runtime/threads.cpp Changeset: 9da5170a Author: Emanuel Peter Date: 2024-04-05 06:48:02 +0000 URL: https://git.openjdk.org/leyden/commit/9da5170a0eb9f141022f86d749af3b5780b75cb7 8327978: C2 SuperWord: Fix compilation time regression in dependency graph traversal after JDK-8325651 Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/vectorization.cpp ! src/hotspot/share/opto/vectorization.hpp + test/hotspot/jtreg/compiler/loopopts/superword/TestLargeCompilation.java Changeset: 6bc6392d Author: Christian Hagedorn Date: 2024-04-05 06:56:54 +0000 URL: https://git.openjdk.org/leyden/commit/6bc6392d2b073434d2cfac4c5f6f2908bd8fe77e 8329201: C2: Replace TypeInterfaces::intersection_with() + eq() with contains() Reviewed-by: kvn, roland ! src/hotspot/share/opto/type.cpp Changeset: 1131bb77 Author: Roberto Casta?eda Lozano Date: 2024-04-05 07:33:14 +0000 URL: https://git.openjdk.org/leyden/commit/1131bb77ec94dd131a10df4ba0f3fab32c65c0f2 8329261: G1: interpreter post-barrier x86 code asserts index size of wrong buffer Reviewed-by: aboldtch, kbarrett ! src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp Changeset: b71acc70 Author: Per Minborg Date: 2024-04-05 07:38:43 +0000 URL: https://git.openjdk.org/leyden/commit/b71acc704a13b816621b9db65b4c5107f2ae032f 8329089: Empty immutable list throws the wrong exception type for remove(first | last) operations Reviewed-by: rriggs ! src/java.base/share/classes/java/util/ImmutableCollections.java ! test/jdk/java/util/Collection/MOAT.java Changeset: 71d48bcc Author: Stefan Karlsson Date: 2024-04-05 07:39:48 +0000 URL: https://git.openjdk.org/leyden/commit/71d48bcc3d6313ab4bd031b5e50ae3a16338abc8 8329655: Cleanup KlassObj and klassOop names after the PermGen removal Reviewed-by: rkennke, coleenp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/cds/archiveHeapWriter.cpp ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/ci/ciTypeArrayKlass.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/memory/heapInspection.cpp ! src/hotspot/share/memory/heapInspection.hpp ! src/hotspot/share/memory/oopFactory.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/prims/vectorSupport.cpp ! src/hotspot/share/runtime/reflection.cpp ! test/hotspot/gtest/oops/test_typeArrayOop.cpp Changeset: 8efe569b Author: Aggelos Biboudis Date: 2024-04-05 08:05:53 +0000 URL: https://git.openjdk.org/leyden/commit/8efe569b8dc0ae865aa75757ca0e5c4cda12aa61 8328747: WrongMethodTypeException with pattern matching on switch on sealed classes Reviewed-by: cushon, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java + test/langtools/tools/javac/T8328747.java Changeset: 8bc1867d Author: Julian Waters Committer: Magnus Ihse Bursie Date: 2024-04-05 08:19:35 +0000 URL: https://git.openjdk.org/leyden/commit/8bc1867da78ea0b7664892ee277af413ef503b61 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler Co-authored-by: Magnus Ihse Bursie Reviewed-by: jwaters, prr ! make/autoconf/flags-cflags.m4 ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DGlyphCache.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Canvas.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Component.cpp ! src/java.desktop/windows/native/libawt/windows/awt_DnDDS.cpp ! src/java.desktop/windows/native/libawt/windows/awt_DnDDT.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp ! src/java.desktop/windows/native/libawt/windows/awt_PrintDialog.h ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp ! src/java.desktop/windows/native/libawt/windows/awt_TextComponent.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Window.cpp ! src/jdk.accessibility/windows/native/libjavaaccessbridge/AccessBridgeJavaEntryPoints.cpp Changeset: 3f4b167c Author: Magnus Ihse Bursie Date: 2024-04-05 08:37:41 +0000 URL: https://git.openjdk.org/leyden/commit/3f4b167c974881f5f7ea1c621c7efe2f550cb60c 8329672: Only call SetupNativeCompilation from SetupJdkNativeCompilation Reviewed-by: erikj ! make/CompileDemos.gmk ! make/Hsdis.gmk ! make/UpdateX11Wrappers.gmk ! make/common/JdkNativeCompilation.gmk ! make/common/TestFilesCompilation.gmk ! make/common/modules/LauncherCommon.gmk ! make/hotspot/gensrc/GenerateSources.gmk ! make/hotspot/gensrc/GensrcAdlc.gmk ! make/hotspot/lib/CompileGtest.gmk ! make/hotspot/lib/CompileJvm.gmk ! make/hotspot/lib/JvmOverrideFiles.gmk ! make/modules/java.base/Lib.gmk ! make/modules/jdk.sctp/Lib.gmk ! make/test/BuildFailureHandler.gmk ! make/test/JtregNativeHotspot.gmk Changeset: 18c925cd Author: Albert Mingkun Yang Date: 2024-04-05 09:59:09 +0000 URL: https://git.openjdk.org/leyden/commit/18c925cd33d6f3b1d4365d582dddaa8426f41bea 8329661: Refactor ScavengableNMethods::verify_unlisted_nmethods Reviewed-by: stefank, iwalulya ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/gc/shared/scavengableNMethods.cpp ! src/hotspot/share/gc/shared/scavengableNMethods.hpp Changeset: 27353ad3 Author: Guoxiong Li Date: 2024-04-05 11:15:14 +0000 URL: https://git.openjdk.org/leyden/commit/27353ad367c2342086d8e56ee2412d796d44b664 8329521: Serial: Rename MarkSweep to SerialFullGC Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/serial/generation.hpp - src/hotspot/share/gc/serial/markSweep.cpp - src/hotspot/share/gc/serial/markSweep.inline.hpp + src/hotspot/share/gc/serial/serialFullGC.cpp = src/hotspot/share/gc/serial/serialFullGC.hpp + src/hotspot/share/gc/serial/serialFullGC.inline.hpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/oops/oop.inline.hpp ! src/hotspot/share/opto/runtime.cpp Changeset: 29992e1f Author: Stefan Karlsson Date: 2024-04-05 12:00:16 +0000 URL: https://git.openjdk.org/leyden/commit/29992e1fca4faef0fe0ac453c7e78db4628d5e70 8329570: G1: Excessive is_obj_dead_cond calls in verification Reviewed-by: aboldtch, shade, tschatzl, gli ! src/hotspot/share/gc/g1/g1HeapRegion.cpp Changeset: 46d3d7b9 Author: Guoxiong Li Date: 2024-04-05 12:16:45 +0000 URL: https://git.openjdk.org/leyden/commit/46d3d7b9673e06c74c8586c164f8a233a8876835 8329529: Serial: Move _saved_mark_word out of ContiguousSpace Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/serial/cardTableRS.cpp ! src/hotspot/share/gc/serial/cardTableRS.hpp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/defNewGeneration.inline.hpp ! src/hotspot/share/gc/serial/generation.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.inline.hpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/space.hpp ! src/hotspot/share/gc/shared/space.inline.hpp ! src/hotspot/share/gc/shared/vmStructs_gc.hpp Changeset: 4a11db8b Author: Jaikiran Pai Date: 2024-04-05 13:30:22 +0000 URL: https://git.openjdk.org/leyden/commit/4a11db8b606f2b10f48f0b45335b661fe3095fc4 8329662: Add a test to verify the behaviour of the default HEAD() method on HttpRequest.Builder Reviewed-by: dfuchs ! test/jdk/java/net/httpclient/HttpRequestBuilderTest.java Changeset: 040c9356 Author: Brian Burkhalter Date: 2024-04-05 16:08:16 +0000 URL: https://git.openjdk.org/leyden/commit/040c93565c0dff6270911eb9e58d78aa01bbb925 8328183: Minor mistakes in docs of PrintStream.append() Reviewed-by: iris, naoto ! src/java.base/share/classes/java/io/CharArrayWriter.java ! src/java.base/share/classes/java/io/PrintStream.java ! src/java.base/share/classes/java/io/PrintWriter.java ! src/java.base/share/classes/java/io/StringWriter.java ! src/java.base/share/classes/java/io/Writer.java Changeset: 862e6156 Author: Alisen Chung Date: 2024-04-05 20:20:28 +0000 URL: https://git.openjdk.org/leyden/commit/862e6156960639564aed5de16de9a26320770a80 8198237: [macos] Test java/awt/Frame/ExceptionOnSetExtendedStateTest/ExceptionOnSetExtendedStateTest.java fails Reviewed-by: gli, aivanov ! test/jdk/ProblemList.txt Changeset: 3d50eaa6 Author: Ioi Lam Date: 2024-04-06 02:25:04 +0000 URL: https://git.openjdk.org/leyden/commit/3d50eaa6edd6ae2b093a75fa203a706aef24701b 8329784: Run MaxMetaspaceSizeTest.java with -Xshare:off Reviewed-by: ccheung, matsaave ! test/hotspot/jtreg/runtime/Metaspace/MaxMetaspaceSizeTest.java Changeset: 49d8e638 Author: Hamlin Li Date: 2024-04-06 06:23:20 +0000 URL: https://git.openjdk.org/leyden/commit/49d8e6383321dcf152f70998be60695cea7527eb 8329083: RISC-V: Update profiles supported on riscv Reviewed-by: fyang ! src/hotspot/cpu/riscv/globals_riscv.hpp ! src/hotspot/cpu/riscv/vm_version_riscv.cpp ! src/hotspot/cpu/riscv/vm_version_riscv.hpp Changeset: d771ec62 Author: Jaikiran Pai Date: 2024-04-06 14:21:57 +0000 URL: https://git.openjdk.org/leyden/commit/d771ec6296bd3bb17ac2dd79671fdb6f154b4ea5 8329733: Update the documentation in java.net.SocketOptions to direct to java.net.StandardSocketOptions 6431396: Spec for SocketOptions.SO_BINDADDR incorrect Reviewed-by: djelinski, alanb ! src/java.base/share/classes/java/net/SocketOptions.java Changeset: 3a3b77dd Author: Gui Cao Committer: Fei Yang Date: 2024-04-08 01:33:49 +0000 URL: https://git.openjdk.org/leyden/commit/3a3b77dd4f522e2ca855acca8516e5901c3f2b5a 8329641: RISC-V: Enable some tests related to SHA-2 instrinsic Reviewed-by: fyang, rehn ! src/hotspot/cpu/riscv/vm_version_riscv.hpp ! test/hotspot/jtreg/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java Changeset: 51b0abc8 Author: Daniel Jeli?ski Date: 2024-04-08 04:30:03 +0000 URL: https://git.openjdk.org/leyden/commit/51b0abc87439014c4c5022c0057614f99a741ddd 8329340: Remove unused libawt code 8315693: Remove WM_AWT_SET_SCROLL_INFO message Reviewed-by: prr, aivanov ! src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c ! src/java.desktop/share/native/libawt/awt/image/imageInitIDs.h ! src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp ! src/java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp ! src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp ! src/java.desktop/windows/native/libawt/windows/awt.h ! src/java.desktop/windows/native/libawt/windows/awt_Component.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Component.h ! src/java.desktop/windows/native/libawt/windows/awt_Cursor.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Debug.h ! src/java.desktop/windows/native/libawt/windows/awt_DnDDS.cpp ! src/java.desktop/windows/native/libawt/windows/awt_DnDDS.h ! src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Object.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Object.h ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h ! src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.h ! src/java.desktop/windows/native/libawt/windows/awt_ole.h ! src/java.desktop/windows/native/libawt/windows/awtmsg.h Changeset: d1aad712 Author: Tobias Hartmann Date: 2024-04-08 07:30:31 +0000 URL: https://git.openjdk.org/leyden/commit/d1aad71209092013a89b3b85a258dd4d2e31224a 8321204: C2: assert(false) failed: node should be in igvn hash table Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/compile.cpp Changeset: 6f087cbc Author: Stefan Karlsson Date: 2024-04-08 09:29:40 +0000 URL: https://git.openjdk.org/leyden/commit/6f087cbcd5c8c91eb104c6e4297f485dd1a82229 8328698: oopDesc::klass_raw() decodes without a null check Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1HeapRegion.cpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/locationPrinter.cpp ! src/hotspot/share/oops/compressedKlass.hpp ! src/hotspot/share/oops/compressedKlass.inline.hpp ! src/hotspot/share/oops/oop.cpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/oop.inline.hpp ! src/hotspot/share/runtime/os.cpp Changeset: 7c664657 Author: Pavel Rappo Date: 2024-04-08 09:50:35 +0000 URL: https://git.openjdk.org/leyden/commit/7c664657630a50ab83d218028cec114ea2d907ac 8325088: Overloads that differ in type parameters may be lost Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIndexBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Comparators.java + test/langtools/jdk/javadoc/doclet/testErasure/TestErasure.java Changeset: fc18201b Author: Christian Hagedorn Date: 2024-04-08 10:52:30 +0000 URL: https://git.openjdk.org/leyden/commit/fc18201bbdac7ac7d78767c780d3efe5352ee77a 8327111: Replace remaining usage of create_bool_from_template_assertion_predicate() which requires additional OpaqueLoop*Nodes transformation strategies Reviewed-by: epeter, kvn ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/predicates.cpp ! src/hotspot/share/opto/predicates.hpp ! test/hotspot/jtreg/compiler/predicates/TestCloningWithManyDiamondsInExpression.java Changeset: 8648890f Author: Tobias Hartmann Date: 2024-04-08 11:35:49 +0000 URL: https://git.openjdk.org/leyden/commit/8648890f86fb3d869950614c97c2df648352168d 8329749: Obsolete the unused UseNeon flag Reviewed-by: chagedorn, kvn, aph ! src/hotspot/cpu/aarch64/globals_aarch64.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/aarch64/AArch64.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/aarch64/AArch64HotSpotJVMCIBackendFactory.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/aarch64/AArch64HotSpotVMConfig.java Changeset: be45de1f Author: Jan Lahoda Date: 2024-04-08 12:13:52 +0000 URL: https://git.openjdk.org/leyden/commit/be45de1f93e918f928c6bb8bebc3697487adf602 8328627: JShell documentation should be clearer about "remote runtime system" Co-authored-by: Alex Buckley Reviewed-by: asotona ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! src/jdk.jshell/share/man/jshell.1 Changeset: 3ebf8c93 Author: Matthias Baesken Date: 2024-04-08 12:55:50 +0000 URL: https://git.openjdk.org/leyden/commit/3ebf8c9359da2f45e4cefb7be2276d33c30979aa 8329663: hs_err file event log entry for thread adding/removing should print current thread Reviewed-by: kevinw, rrich ! src/hotspot/share/runtime/threads.cpp Changeset: 6439375b Author: Matias Saavedra Silva Date: 2024-04-08 14:06:43 +0000 URL: https://git.openjdk.org/leyden/commit/6439375bb96346f4b34ba57e8e61ffe1905563f1 8329533: TestCDSVMCrash fails on libgraal Reviewed-by: iklam, ccheung ! test/hotspot/jtreg/runtime/cds/TestCDSVMCrash.java Changeset: 74758248 Author: Alexey Ivanov Date: 2024-04-08 15:27:58 +0000 URL: https://git.openjdk.org/leyden/commit/747582484ce89e16661ef917a89adb52f5adc2e6 8329510: Update ProblemList for JFileChooser/8194044/FileSystemRootTest.java Reviewed-by: abhiscxk, dmarkov ! test/jdk/ProblemList.txt Changeset: 9ac3b77d Author: Albert Mingkun Yang Date: 2024-04-08 15:55:53 +0000 URL: https://git.openjdk.org/leyden/commit/9ac3b77d0d69227ded6ef3843ebf5c18ceee37b5 8329775: Serial: Remove unused declarations in serialFullGC.hpp Reviewed-by: iwalulya ! src/hotspot/share/gc/serial/serialFullGC.hpp Changeset: 115f4193 Author: Guoxiong Li Date: 2024-04-08 16:10:07 +0000 URL: https://git.openjdk.org/leyden/commit/115f4193eb39d8469ac8127e38798a3f041c22e0 8329659: Serial: Extract allowed_dead_ratio from ContiguousSpace Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/serial/serialFullGC.cpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/space.hpp Changeset: dd930c57 Author: Naoto Sato Date: 2024-04-08 16:26:02 +0000 URL: https://git.openjdk.org/leyden/commit/dd930c573b2822e7f55e9d1b9a945a023c3fdee6 8329787: Fix typo in CLDRConverter Reviewed-by: jlu, iris, lancea, bpb ! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java - make/jdk/src/classes/build/tools/cldrconverter/SupplementDataParseHandler.java + make/jdk/src/classes/build/tools/cldrconverter/SupplementalDataParseHandler.java ! make/jdk/src/classes/build/tools/cldrconverter/SupplementalMetadataParseHandler.java Changeset: 212a2536 Author: Roger Riggs Date: 2024-04-08 17:58:21 +0000 URL: https://git.openjdk.org/leyden/commit/212a253697b1a5e722bb90ae1140c91175fc028b 8329623: NegativeArraySizeException encoding large String to UTF-8 Reviewed-by: naoto, rgiulietti ! src/java.base/share/classes/java/lang/String.java ! test/jdk/java/lang/String/CompactString/MaxSizeUTF16String.java Changeset: a4dd2e95 Author: Albert Mingkun Yang Date: 2024-04-08 18:33:59 +0000 URL: https://git.openjdk.org/leyden/commit/a4dd2e95322dd5af9c576a1d401368a4286451a9 8329766: Serial: Refactor SerialBlockOffsetTable API Reviewed-by: gli, iwalulya ! src/hotspot/share/gc/serial/serialBlockOffsetTable.cpp ! src/hotspot/share/gc/serial/serialBlockOffsetTable.hpp Changeset: 94677200 Author: Albert Mingkun Yang Date: 2024-04-08 18:34:09 +0000 URL: https://git.openjdk.org/leyden/commit/94677200fb68a542ffc45221df5c27dfbdf47932 8329875: Serial: Move preservedMarks.inline.hpp to serialFullGC.cpp Reviewed-by: stefank ! src/hotspot/share/gc/serial/serialFullGC.cpp ! src/hotspot/share/gc/serial/serialFullGC.hpp Changeset: 7e5ef79f Author: vamsi-parasa Committer: Sandhya Viswanathan Date: 2024-04-08 18:41:32 +0000 URL: https://git.openjdk.org/leyden/commit/7e5ef79f953877cde6389998edcfe3fecb9b900e 8323116: [REDO] Computational test more than 2x slower when AVX instructions are used Reviewed-by: sviswanathan, kvn ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/x86_64.ad + test/hotspot/jtreg/compiler/codegen/TestConvertImplicitNullCheck.java + test/micro/org/openjdk/bench/vm/compiler/x86/ComputePI.java Changeset: e7026465 Author: Sean Mullan Date: 2024-04-08 20:08:56 +0000 URL: https://git.openjdk.org/leyden/commit/e70264654570155a39d0841ce82b9dd52ca0389c 8200566: DistributionPointFetcher fails to fetch CRLs if the DistributionPoints field contains more than one DistributionPoint and the first one fails Reviewed-by: weijun ! src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java + test/jdk/java/security/cert/CertPathValidator/crlDP/CheckAllCRLs.java Changeset: a887fd21 Author: Cesar Soares Lucas Committer: Vladimir Kozlov Date: 2024-04-08 23:13:38 +0000 URL: https://git.openjdk.org/leyden/commit/a887fd2144ce067844f18a514afb5078255601ff 8316991: Reduce nullable allocation merges Reviewed-by: kvn, vlivanov ! src/hotspot/share/code/debugInfo.cpp ! src/hotspot/share/code/debugInfo.hpp ! src/hotspot/share/code/scopeDesc.cpp ! src/hotspot/share/opto/castnode.hpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/escape.hpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/subnode.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/stackValue.cpp ! test/hotspot/jtreg/compiler/c2/irTests/scalarReplacement/AllocationMergesTests.java + test/micro/org/openjdk/bench/vm/compiler/AllocationMerges.java Changeset: fbc1e666 Author: Jatin Bhateja Date: 2024-04-09 01:37:38 +0000 URL: https://git.openjdk.org/leyden/commit/fbc1e6661e26c30a9cf7bc57afd70fde1c642bcb 8328181: C2: assert(MaxVectorSize >= 32) failed: vector length should be >= 32 Reviewed-by: kvn, vlivanov ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad ! test/hotspot/jtreg/compiler/c2/ClearArray.java Changeset: dfaf11a3 Author: David Holmes Date: 2024-04-09 07:40:45 +0000 URL: https://git.openjdk.org/leyden/commit/dfaf11a3d80792ae9c484f3c21f93d0b7b0d23f9 8329898: Revert one use of markWord.is_unlocked back to is_neutral Reviewed-by: stefank ! src/hotspot/share/runtime/basicLock.cpp Changeset: b4ddddef Author: Axel Boldt-Christmas Date: 2024-04-09 08:11:04 +0000 URL: https://git.openjdk.org/leyden/commit/b4ddddeff1ce4293c88a9ab8ad3ca9d3b0e2352e 8329840: Fix ZPhysicalMemorySegment::_end type Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zAddress.inline.hpp ! src/hotspot/share/gc/z/zPhysicalMemory.hpp ! src/hotspot/share/gc/z/zPhysicalMemory.inline.hpp ! test/hotspot/gtest/gc/z/test_zPhysicalMemory.cpp Changeset: 19a99d02 Author: Adam Sotona Date: 2024-04-09 08:41:36 +0000 URL: https://git.openjdk.org/leyden/commit/19a99d023e32fa9f4d26b76bd36993719e1dfe21 8326744: Class-File API transition to Second Preview Reviewed-by: jlahoda ! src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java Changeset: 58e39c19 Author: Jie Fu Date: 2024-04-09 08:47:30 +0000 URL: https://git.openjdk.org/leyden/commit/58e39c193211579316cfd09dc4117d510e317985 8329884: Serial: Fix build failure due to ?Copy? has not been declared Reviewed-by: ayang ! src/hotspot/share/gc/serial/tenuredGeneration.cpp Changeset: 71c5bbce Author: Adam Sotona Date: 2024-04-09 09:35:07 +0000 URL: https://git.openjdk.org/leyden/commit/71c5bbcec7052a8394dd49c0a8c46801adbfcae4 8329527: Opcode.IFNONNULL.primaryTypeKind() is not ReferenceType Reviewed-by: jlahoda ! src/java.base/share/classes/java/lang/classfile/Opcode.java Changeset: b9331cd2 Author: Gui Cao Committer: Fei Yang Date: 2024-04-09 10:41:28 +0000 URL: https://git.openjdk.org/leyden/commit/b9331cd25ca88b07ce079405f5e3031cf8c13ea6 8329823: RISC-V: Need to sync CPU features with related JVM flags Reviewed-by: fyang, rehn ! src/hotspot/cpu/riscv/vm_version_riscv.hpp ! src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp Changeset: 8907eda7 Author: Adam Sotona Date: 2024-04-09 11:08:10 +0000 URL: https://git.openjdk.org/leyden/commit/8907eda779f0c3f870bb31deb74c0a483251f1e2 8325485: IncrementInstructions.of(int, int) is not storing the args Reviewed-by: liach, jlahoda ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java ! test/jdk/jdk/classfile/CorpusTest.java ! test/jdk/jdk/classfile/helpers/ClassRecord.java ! test/jdk/jdk/classfile/helpers/RebuildingTransformation.java Changeset: a48289ac Author: Alexey Ivanov Date: 2024-04-09 11:40:10 +0000 URL: https://git.openjdk.org/leyden/commit/a48289ac30a6a9ddc9941676726d105b11689ab3 8329761: Remove unused KeyBuilder and unusedSets from StyleContext Reviewed-by: serb, tr ! src/java.desktop/share/classes/javax/swing/text/StyleContext.java Changeset: 5ea21c3a Author: Albert Mingkun Yang Date: 2024-04-09 12:26:52 +0000 URL: https://git.openjdk.org/leyden/commit/5ea21c3a61a7a159d1b88885368741763f42bf04 8329878: Reduce public interface of CardTableBarrierSet Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/cardTableBarrierSet.hpp Changeset: 87131fb2 Author: Stefan Karlsson Date: 2024-04-09 12:27:55 +0000 URL: https://git.openjdk.org/leyden/commit/87131fb2f77188a483fd0852da5f9228aafd5336 8329629: GC interfaces should work directly against nmethod instead of CodeBlob Reviewed-by: ayang, eosterlund ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp - src/hotspot/share/gc/g1/g1CodeBlobClosure.cpp - src/hotspot/share/gc/g1/g1CodeBlobClosure.hpp ! src/hotspot/share/gc/g1/g1CodeRootSet.cpp ! src/hotspot/share/gc/g1/g1CodeRootSet.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1FullGCAdjustTask.cpp ! src/hotspot/share/gc/g1/g1FullGCMarkTask.cpp ! src/hotspot/share/gc/g1/g1HeapRegion.cpp ! src/hotspot/share/gc/g1/g1HeapRegion.hpp ! src/hotspot/share/gc/g1/g1HeapRegionRemSet.cpp ! src/hotspot/share/gc/g1/g1HeapRegionRemSet.hpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp + src/hotspot/share/gc/g1/g1NMethodClosure.cpp + src/hotspot/share/gc/g1/g1NMethodClosure.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/g1RemSet.hpp ! src/hotspot/share/gc/g1/g1RootClosures.cpp ! src/hotspot/share/gc/g1/g1RootClosures.hpp ! src/hotspot/share/gc/g1/g1RootProcessor.cpp ! src/hotspot/share/gc/g1/g1RootProcessor.hpp ! src/hotspot/share/gc/g1/g1SharedClosures.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/serialFullGC.cpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/gc/shared/classUnloadingContext.cpp ! src/hotspot/share/gc/shared/classUnloadingContext.hpp ! src/hotspot/share/gc/shared/scavengableNMethods.cpp ! src/hotspot/share/gc/shared/scavengableNMethods.hpp ! src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp ! src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootVerifier.cpp ! src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.hpp ! src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp ! src/hotspot/share/gc/x/xHeap.cpp ! src/hotspot/share/gc/x/xHeapIterator.cpp ! src/hotspot/share/gc/x/xStackWatermark.cpp ! src/hotspot/share/gc/x/xStackWatermark.hpp ! src/hotspot/share/gc/x/xVerify.cpp ! src/hotspot/share/gc/z/zGeneration.cpp ! src/hotspot/share/gc/z/zHeapIterator.cpp ! src/hotspot/share/gc/z/zStackWatermark.cpp ! src/hotspot/share/gc/z/zStackWatermark.hpp ! src/hotspot/share/gc/z/zVerify.cpp ! src/hotspot/share/memory/iterator.cpp ! src/hotspot/share/memory/iterator.hpp ! src/hotspot/share/prims/jvmtiImpl.cpp ! src/hotspot/share/prims/jvmtiImpl.hpp ! src/hotspot/share/prims/jvmtiThreadState.cpp ! src/hotspot/share/prims/jvmtiThreadState.hpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/frame.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/serviceThread.cpp ! src/hotspot/share/runtime/serviceThread.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/threads.cpp ! src/hotspot/share/runtime/threads.hpp Changeset: 492b954f Author: Stefan Karlsson Date: 2024-04-09 12:31:13 +0000 URL: https://git.openjdk.org/leyden/commit/492b954f81f75cedec50fabc4e6071cabb53acc0 8329750: Change Universe functions to return more specific Klass* types Reviewed-by: coleenp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/memory/oopFactory.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/prims/vectorSupport.cpp Changeset: 5c9f0368 Author: Stefan Karlsson Date: 2024-04-09 12:32:17 +0000 URL: https://git.openjdk.org/leyden/commit/5c9f03686d77dd56c0441f9eb54b1cfcd3a49b3c 8329858: G1: Make G1VerifyLiveAndRemSetClosure stateless Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1HeapRegion.cpp Changeset: 635cb3c9 Author: Jaikiran Pai Date: 2024-04-09 13:04:14 +0000 URL: https://git.openjdk.org/leyden/commit/635cb3c9762aeaec6c8dd2c21b8323d187236b4f 8329745: Update the documentation of ServerSocket and Socket to refer to StandardSocketOptions instead of legacy SocketOptions Reviewed-by: alanb, dfuchs ! src/java.base/share/classes/java/net/ServerSocket.java ! src/java.base/share/classes/java/net/Socket.java Changeset: 2fcb8168 Author: Alexey Ivanov Date: 2024-04-09 13:19:41 +0000 URL: https://git.openjdk.org/leyden/commit/2fcb816858406f33cefef3164b2c85f9f996c7da 8305072: Win32ShellFolder2.compareTo is inconsistent Reviewed-by: prr, serb ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java + test/jdk/javax/swing/JFileChooser/FileSystemView/Win32FolderSort.java Changeset: 5fb5e6c8 Author: Guoxiong Li Date: 2024-04-09 13:22:24 +0000 URL: https://git.openjdk.org/leyden/commit/5fb5e6c8f04e325cbb782431d51251edde4c2618 8329603: G1: Merge G1BlockOffsetTablePart into G1BlockOffsetTable Reviewed-by: ayang, iwalulya ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1HeapRegion.cpp ! src/hotspot/share/gc/g1/g1HeapRegion.hpp ! src/hotspot/share/gc/g1/g1HeapRegion.inline.hpp Changeset: 3b6629ce Author: Daniel Jeli?ski Date: 2024-04-09 14:10:58 +0000 URL: https://git.openjdk.org/leyden/commit/3b6629cec7a2ecec8dcb5b94d8ed3e169483aa97 8324673: javacserver failed during build: RejectedExecutionException Reviewed-by: cstein, erikj ! make/langtools/tools/javacserver/server/CompilerThreadPool.java ! make/langtools/tools/javacserver/server/Server.java Changeset: a8fbeec9 Author: Albert Mingkun Yang Date: 2024-04-09 14:26:31 +0000 URL: https://git.openjdk.org/leyden/commit/a8fbeec9e968d82c66d739d6e70fd24795af0770 8329956: G1: Remove unimplemented collection_set_candidate_short_type_str Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/g1HeapRegion.hpp Changeset: f9bc2db9 Author: Adam Sotona Date: 2024-04-09 14:41:39 +0000 URL: https://git.openjdk.org/leyden/commit/f9bc2db9a9b8e5b7314fba5f70cb79e07ed02bd8 8325371: Missing ClassFile.Option in package summary Reviewed-by: briangoetz ! src/java.base/share/classes/java/lang/classfile/ClassFile.java ! src/java.base/share/classes/java/lang/classfile/package-info.java Changeset: e75e1cb0 Author: Adam Sotona Date: 2024-04-09 14:44:00 +0000 URL: https://git.openjdk.org/leyden/commit/e75e1cb02c3d115762846e47fb2d2b10a177f6de 8329955: Class-File API ClassPrinter does not print bootstrap methods arguments Reviewed-by: briangoetz ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java ! test/jdk/jdk/classfile/ClassPrinterTest.java Changeset: 2e925f26 Author: Roman Kennke Date: 2024-04-09 14:50:41 +0000 URL: https://git.openjdk.org/leyden/commit/2e925f263d5a9a69f21e0c12bd71242fdff084cd 8329726: Use non-short forward jumps in lightweight locking Reviewed-by: shade, kvn, aboldtch ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp + test/hotspot/jtreg/compiler/c2/TestLWLockingCodeGen.java Changeset: 23d161de Author: Robbin Ehn Date: 2024-04-09 15:00:50 +0000 URL: https://git.openjdk.org/leyden/commit/23d161de2904208b71c50f7e54870ab0bd1eb2fe 8328630: Add logging when needed symbols in dll are missing. Reviewed-by: dholmes, luhenry, mli ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/windows/os_windows.cpp Changeset: 1e02a13a Author: Robbin Ehn Date: 2024-04-09 15:01:02 +0000 URL: https://git.openjdk.org/leyden/commit/1e02a13a7f02a6fe9aac38b93935bcc238f7d227 8328614: hsdis: dlsym can't find decode symbol Reviewed-by: ihse, luhenry, mli ! make/Hsdis.gmk ! src/utils/hsdis/binutils/hsdis-binutils.c ! src/utils/hsdis/capstone/hsdis-capstone.c ! src/utils/hsdis/hsdis.h ! src/utils/hsdis/llvm/hsdis-llvm.cpp Changeset: 6736792b Author: Vladimir Kozlov Date: 2024-04-09 15:32:15 +0000 URL: https://git.openjdk.org/leyden/commit/6736792b9a711b82b21a5f32cde55f2a3f15ffda 8329628: Additional changes after JDK-8329332 Reviewed-by: stefank, eosterlund ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp ! src/hotspot/cpu/arm/frame_arm.cpp ! src/hotspot/cpu/arm/frame_arm.inline.hpp ! src/hotspot/cpu/ppc/frame_ppc.cpp ! src/hotspot/cpu/ppc/frame_ppc.inline.hpp ! src/hotspot/cpu/riscv/frame_riscv.cpp ! src/hotspot/cpu/riscv/frame_riscv.inline.hpp ! src/hotspot/cpu/s390/frame_s390.cpp ! src/hotspot/cpu/s390/frame_s390.inline.hpp ! src/hotspot/cpu/x86/frame_x86.cpp ! src/hotspot/cpu/x86/frame_x86.inline.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/code/compiledIC.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/code/nmethod.inline.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/gc/shared/parallelCleaning.cpp ! src/hotspot/share/gc/shared/scavengableNMethods.cpp ! src/hotspot/share/gc/z/zNMethod.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/frame.hpp ! src/hotspot/share/runtime/frame.inline.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp Changeset: 4bba445d Author: Evgeny Nikitin Committer: Paul Sandoz Date: 2024-04-09 15:39:51 +0000 URL: https://git.openjdk.org/leyden/commit/4bba445d835837db5ab145edb24030fc6f42ec24 8325659: Normalize Random usage by incubator vector tests Reviewed-by: psandoz ! test/jdk/jdk/incubator/vector/AbstractVectorTest.java ! test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte128VectorTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Double128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double128VectorTests.java ! test/jdk/jdk/incubator/vector/Double256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double256VectorTests.java ! test/jdk/jdk/incubator/vector/Double512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double512VectorTests.java ! test/jdk/jdk/incubator/vector/Double64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double64VectorTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Float128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float128VectorTests.java ! test/jdk/jdk/incubator/vector/Float256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float256VectorTests.java ! test/jdk/jdk/incubator/vector/Float512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float512VectorTests.java ! test/jdk/jdk/incubator/vector/Float64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float64VectorTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Int128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int128VectorTests.java ! test/jdk/jdk/incubator/vector/Int256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int256VectorTests.java ! test/jdk/jdk/incubator/vector/Int512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int512VectorTests.java ! test/jdk/jdk/incubator/vector/Int64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int64VectorTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Long128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long128VectorTests.java ! test/jdk/jdk/incubator/vector/Long256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long256VectorTests.java ! test/jdk/jdk/incubator/vector/Long512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long512VectorTests.java ! test/jdk/jdk/incubator/vector/Long64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long64VectorTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Short128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short128VectorTests.java ! test/jdk/jdk/incubator/vector/Short256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short256VectorTests.java ! test/jdk/jdk/incubator/vector/Short512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short512VectorTests.java ! test/jdk/jdk/incubator/vector/Short64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short64VectorTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java ! test/jdk/jdk/incubator/vector/templates/Kernel-Slice-Masked-bop.template ! test/jdk/jdk/incubator/vector/templates/Kernel-Slice-bop.template ! test/jdk/jdk/incubator/vector/templates/Kernel-Slice-op.template ! test/jdk/jdk/incubator/vector/templates/Kernel-Unslice-Masked-bop.template ! test/jdk/jdk/incubator/vector/templates/Kernel-Unslice-bop.template ! test/jdk/jdk/incubator/vector/templates/Kernel-Unslice-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-header.template ! test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template Changeset: b80ba085 Author: Vladimir Kozlov Date: 2024-04-09 16:20:43 +0000 URL: https://git.openjdk.org/leyden/commit/b80ba0851841a8490e61371ac4ef3514dc6eddf5 8329967: Build failure after JDK-8329628 Reviewed-by: thartmann, shade, dcubed ! src/hotspot/share/code/codeCache.cpp Changeset: 316361b9 Author: Ben Perez Committer: Sean Mullan Date: 2024-04-09 20:03:18 +0000 URL: https://git.openjdk.org/leyden/commit/316361b95c004f5dcd6e7a3150cebceb8f82f67b 8328318: Wrong description in X509Extension.getExtensionValue method javadoc Reviewed-by: mullan, wetmore ! src/java.base/share/classes/java/security/cert/X509Extension.java Changeset: 6276789f Author: Valerie Peng Date: 2024-04-09 21:51:51 +0000 URL: https://git.openjdk.org/leyden/commit/6276789fb5e283c11ac73602c2a5f646eab96975 8328785: IOException: Symbol not found: C_GetInterface for PKCS11 interface prior to V3.0 Reviewed-by: djelinski, weijun ! src/jdk.crypto.cryptoki/unix/native/libj2pkcs11/p11_md.c Changeset: b81b86da Author: Jaikiran Pai Date: 2024-04-10 01:33:13 +0000 URL: https://git.openjdk.org/leyden/commit/b81b86da9849fbc4fb341bff8a23d10aee9967b3 8329729: java/util/Properties/StoreReproducibilityTest.java times out Reviewed-by: alanb ! test/jdk/java/util/Properties/StoreReproducibilityTest.java Changeset: 47df1459 Author: Amit Kumar Date: 2024-04-10 03:33:24 +0000 URL: https://git.openjdk.org/leyden/commit/47df14590c003ccb1607ec0edfe999fcf2aebd86 8310513: [s390x] Intrinsify recursive ObjectMonitor locking Reviewed-by: lucy, mdoerr ! src/hotspot/cpu/s390/macroAssembler_s390.cpp Changeset: bab70193 Author: Ioi Lam Date: 2024-04-10 04:14:10 +0000 URL: https://git.openjdk.org/leyden/commit/bab70193ddaae66a1f9039b0f1af1a0dc0e39cf9 8329431: Improve speed of writing CDS heap objects Reviewed-by: ccheung, matsaave ! src/hotspot/share/cds/archiveHeapWriter.cpp ! src/hotspot/share/cds/archiveHeapWriter.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! test/hotspot/jtreg/runtime/cds/appcds/LotsOfClasses.java ! test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java Changeset: d037a597 Author: Boris Ulasevich Date: 2024-04-10 06:29:44 +0000 URL: https://git.openjdk.org/leyden/commit/d037a597a94edf6e716098b88f42f2b15518e2bd 8311248: Refactor CodeCache::initialize_heaps to simplify adding new CodeCache segments Reviewed-by: thartmann ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/memory/virtualspace.cpp ! src/hotspot/share/memory/virtualspace.hpp ! test/hotspot/jtreg/compiler/codecache/CheckSegmentedCodeCache.java Changeset: bea9acc5 Author: Tejesh R Date: 2024-04-10 07:11:02 +0000 URL: https://git.openjdk.org/leyden/commit/bea9acc55a7b0463a1b0b4dcb557f8ea17d8fe8c 8328482: Convert and Open source few manual applet test to main based Reviewed-by: abhiscxk, honkar, prr ! test/jdk/ProblemList.txt + test/jdk/java/awt/Frame/FrameMaximizedTest.java + test/jdk/java/awt/Frame/FrameMinimizeTest.java + test/jdk/java/awt/Frame/MegaIconTest/MegaIconTest.java + test/jdk/java/awt/Frame/MegaIconTest/dukeWave.gif + test/jdk/java/awt/Frame/MegaIconTest/duke_404.gif = test/jdk/java/awt/Frame/MegaIconTest/fight.gif + test/jdk/java/awt/Frame/SizeMinimizedTest.java Changeset: 51ed69a5 Author: Johan Sj?len Date: 2024-04-10 08:12:47 +0000 URL: https://git.openjdk.org/leyden/commit/51ed69a586105b707ae616f9eba898449bf9fba7 8327621: Check return value of uname in os::get_host_name Reviewed-by: dholmes, stuefe ! src/hotspot/os/posix/os_posix.cpp Changeset: e0fd6c4c Author: Sidraya Jayagond Committer: Amit Kumar Date: 2024-04-10 10:12:21 +0000 URL: https://git.openjdk.org/leyden/commit/e0fd6c4c9e30ef107ea930c8ecc449842ae4b8d4 8329545: [s390x] Fix garbage value being passed in Argument Register Reviewed-by: amitkumar, mdoerr ! src/hotspot/cpu/s390/foreignGlobals_s390.cpp Changeset: dd6e4533 Author: Guoxiong Li Date: 2024-04-10 10:26:26 +0000 URL: https://git.openjdk.org/leyden/commit/dd6e4533eb8b9c33b03a041d7a9ac87160ff9ffb 8329767: G1: Move G1BlockOffsetTable::set_for_starts_humongous to HeapRegion Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1HeapRegion.cpp Changeset: b49ba426 Author: Albert Mingkun Yang Date: 2024-04-10 10:32:32 +0000 URL: https://git.openjdk.org/leyden/commit/b49ba426a721db5926ac1b45d573d468389d479c 8330002: Remove redundant public keyword in BarrierSet Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/barrierSet.hpp Changeset: 86cb7672 Author: Darragh Clarke Date: 2024-04-10 11:12:40 +0000 URL: https://git.openjdk.org/leyden/commit/86cb76728dd164faa8fe69cd07db85977e79be29 8326568: jdk/test/com/sun/net/httpserver/bugs/B6431193.java should use try-with-resource and try-finally Reviewed-by: dfuchs, jpai ! test/jdk/com/sun/net/httpserver/bugs/B6431193.java Changeset: c5150c7b Author: Coleen Phillimore Date: 2024-04-10 12:38:07 +0000 URL: https://git.openjdk.org/leyden/commit/c5150c7b81e2b7b8c9e13c228d3b7bcb9dfe5024 8309751: Duplicate constant pool entries added during default method processing Co-authored-by: Ashutosh Mehra Reviewed-by: matsaave, dholmes ! src/hotspot/share/classfile/bytecodeAssembler.cpp ! src/hotspot/share/classfile/bytecodeAssembler.hpp ! src/hotspot/share/classfile/defaultMethods.cpp Changeset: 9731b1c8 Author: Alexey Ivanov Date: 2024-04-10 14:21:37 +0000 URL: https://git.openjdk.org/leyden/commit/9731b1c8b02d957985f4fb40acd93fb67747a9f0 8327137: Add test for ConcurrentModificationException in BasicDirectoryModel Reviewed-by: serb, tr + test/jdk/javax/swing/plaf/basic/BasicDirectoryModel/ConcurrentModification.java Changeset: 279ed0dd Author: Johan Sj?len Date: 2024-04-10 15:16:25 +0000 URL: https://git.openjdk.org/leyden/commit/279ed0ddd505fb3052b818f755b4b220ed5557e6 8329961: Buffer overflow in os::Linux::kernel_version Reviewed-by: rehn, stuefe ! src/hotspot/os/linux/os_linux.cpp Changeset: 70944ca5 Author: Darragh Clarke Date: 2024-04-10 16:11:06 +0000 URL: https://git.openjdk.org/leyden/commit/70944ca54ad0090c734bb5b3082beb33450c4877 8330033: com/sun/net/httpserver/bugs/B6431193.java fails in AssertionError after JDK-8326568 Reviewed-by: jpai, dfuchs ! test/jdk/com/sun/net/httpserver/bugs/B6431193.java Changeset: 643dd48a Author: Serguei Spitsyn Date: 2024-04-11 01:14:20 +0000 URL: https://git.openjdk.org/leyden/commit/643dd48a2aa05388c55fa728a22885540b967a05 8329432: PopFrame and ForceEarlyReturn functions should use JvmtiHandshake Reviewed-by: pchilanomate, lmesnik ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiEnvBase.hpp Changeset: 5e544f15 Author: Serguei Spitsyn Date: 2024-04-11 04:19:02 +0000 URL: https://git.openjdk.org/leyden/commit/5e544f15100366f4e2db58cb0e28cdfd292fe35f 8329491: GetThreadListStackTraces function should use JvmtiHandshake Reviewed-by: pchilanomate, lmesnik ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiEnvBase.hpp Changeset: d9c84e76 Author: Thomas Stuefe Date: 2024-04-11 05:24:33 +0000 URL: https://git.openjdk.org/leyden/commit/d9c84e763a0880d33586dbb8dc90b66ede030444 8329656: assertion failed in MAP_ARCHIVE_MMAP_FAILURE path: Invalid immediate -5 0 Reviewed-by: ccheung, iklam ! src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp Changeset: b04b3047 Author: Jatin Bhateja Date: 2024-04-11 06:28:26 +0000 URL: https://git.openjdk.org/leyden/commit/b04b3047ff5c5526bdf47925210e2a35ca191e6e 8329254: optimize integral reverse operations on x86 GFNI target. Reviewed-by: sviswanathan ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/x86_64.ad Changeset: 2ceeb6c0 Author: Roland Westrelin Date: 2024-04-11 07:27:33 +0000 URL: https://git.openjdk.org/leyden/commit/2ceeb6c00135310b7bdabacb92d26d81de525240 8328822: C2: "negative trip count?" assert failure in profile predicate code Reviewed-by: shade, chagedorn ! src/hotspot/share/opto/loopPredicate.cpp + test/hotspot/jtreg/compiler/predicates/TestCountedLoopMinJintStride.java Changeset: 7df49262 Author: Roland Westrelin Date: 2024-04-11 07:27:44 +0000 URL: https://git.openjdk.org/leyden/commit/7df492627b933f48750985c26de69be3f86115cb 8327741: JVM crash in hotspot/share/opto/compile.cpp - failed: missing inlining msg Reviewed-by: vlivanov, chagedorn ! src/hotspot/share/opto/callGenerator.cpp + test/hotspot/jtreg/compiler/print/TestPrintInliningLateVirtualCall.java Changeset: f7786426 Author: Matthias Baesken Date: 2024-04-11 08:46:19 +0000 URL: https://git.openjdk.org/leyden/commit/f7786426133e0e53c750dfb81272191b08b03652 8330024: [AIX] replace my_disclaim64 helper by direct call to disclaim64 Reviewed-by: mdoerr, lucy ! src/hotspot/os/aix/os_aix.cpp Changeset: 8817ba45 Author: Axel Boldt-Christmas Date: 2024-04-11 08:52:01 +0000 URL: https://git.openjdk.org/leyden/commit/8817ba450c0eac6f7c1ff19b16c11a26ff2ed109 8330000: ZGC: ZObjArrayAllocator may unnecessarily clear TypeArrays twice Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zObjArrayAllocator.cpp Changeset: f0cd866a Author: Magnus Ihse Bursie Date: 2024-04-11 09:40:12 +0000 URL: https://git.openjdk.org/leyden/commit/f0cd866a375082e14c69ccd3bf5e3d4d18edaebf 8329704: Implement framework for proper handling of JDK_LIBS Reviewed-by: erikj, jwaters ! make/autoconf/flags-cflags.m4 ! make/autoconf/flags-ldflags.m4 ! make/autoconf/libraries.m4 ! make/autoconf/spec.gmk.template ! make/common/JdkNativeCompilation.gmk ! make/common/NativeCompilation.gmk ! make/common/TestFilesCompilation.gmk ! make/common/modules/LauncherCommon.gmk ! make/common/modules/LibCommon.gmk ! make/common/native/Link.gmk ! make/common/native/LinkMicrosoft.gmk ! make/hotspot/lib/CompileGtest.gmk ! make/modules/java.base/Lib.gmk ! make/modules/java.base/lib/CoreLibraries.gmk ! make/modules/java.desktop/Lib.gmk ! make/modules/java.desktop/lib/Awt2dLibraries.gmk ! make/modules/java.instrument/Lib.gmk ! make/modules/java.management/Lib.gmk ! make/modules/java.prefs/Lib.gmk ! make/modules/java.rmi/Lib.gmk ! make/modules/java.security.jgss/Lib.gmk ! make/modules/java.smartcardio/Lib.gmk ! make/modules/jdk.accessibility/Lib.gmk ! make/modules/jdk.attach/Lib.gmk ! make/modules/jdk.crypto.cryptoki/Lib.gmk ! make/modules/jdk.crypto.mscapi/Lib.gmk ! make/modules/jdk.hotspot.agent/Lib.gmk ! make/modules/jdk.internal.le/Lib.gmk ! make/modules/jdk.jdi/Lib.gmk ! make/modules/jdk.jdwp.agent/Lib.gmk ! make/modules/jdk.management.agent/Lib.gmk ! make/modules/jdk.management/Lib.gmk ! make/modules/jdk.net/Lib.gmk ! make/modules/jdk.sctp/Lib.gmk ! make/modules/jdk.security.auth/Lib.gmk ! make/test/JtregNativeHotspot.gmk ! make/test/JtregNativeJdk.gmk ! make/test/JtregNativeLibTest.gmk Changeset: 9acce7a6 Author: Ludvig Janiuk Date: 2024-04-11 10:33:19 +0000 URL: https://git.openjdk.org/leyden/commit/9acce7a6f326543c302ca0408213cf333f5f778a 8329774: Break long lines in jdk/src/jdk.hotspot.agent/doc /transported_core.html Reviewed-by: kevinw ! src/jdk.hotspot.agent/doc/transported_core.html Changeset: ff5c9a4d Author: Thomas Schatzl Date: 2024-04-11 11:35:07 +0000 URL: https://git.openjdk.org/leyden/commit/ff5c9a4ddecbe3ee453a30fcfd49fd677c174f06 8329528: G1 does not update TAMS correctly when dropping retained regions during Concurrent Start pause Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/g1YoungGCPreEvacuateTasks.hpp + test/hotspot/jtreg/gc/g1/pinnedobjs/TestDroppedRetainedTAMS.java Changeset: ecc603ca Author: Daniel Jeli?ski Date: 2024-04-11 12:42:24 +0000 URL: https://git.openjdk.org/leyden/commit/ecc603ca9b441cbb7ad27fbc2529fcb0b1da1992 8201183: sjavac build failures: "Connection attempt failed: Connection refused" Reviewed-by: erikj, ihse ! make/langtools/tools/javacserver/shared/PortFile.java Changeset: 63684cd1 Author: Coleen Phillimore Date: 2024-04-11 13:17:48 +0000 URL: https://git.openjdk.org/leyden/commit/63684cd18300d862f3128bd13995e5c82307b50c 8327250: assert(!method->is_old()) failed: Should not be installing old methods Reviewed-by: eosterlund, sspitsyn ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/linkResolver.hpp Changeset: 2e3682a7 Author: Mahendra Chhipa Date: 2024-04-11 13:51:07 +0000 URL: https://git.openjdk.org/leyden/commit/2e3682a7f2983cd58b9564253dc698760faba4b8 8319678: Several tests from corelibs areas ignore VM flags Reviewed-by: naoto, jpai ! test/jdk/java/lang/Thread/UncaughtExceptionsTest.java ! test/jdk/java/lang/annotation/LoaderLeakTest.java ! test/jdk/java/rmi/reliability/benchmark/bench/rmi/Main.java ! test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java ! test/jdk/javax/naming/spi/providers/InitialContextTest.java ! test/jdk/sun/misc/EscapePath.java Changeset: 16061874 Author: Magnus Ihse Bursie Date: 2024-04-11 14:15:34 +0000 URL: https://git.openjdk.org/leyden/commit/16061874ffdd1b018fe1cad7e6d8ba8bdbdbbee1 8326947: Minimize MakeBase.gmk Reviewed-by: erikj ! make/Bundles.gmk ! make/CompileDemos.gmk ! make/CompileInterimLangtools.gmk ! make/CompileToolsJdk.gmk ! make/CopyImportModules.gmk ! make/CopyInterimTZDB.gmk ! make/CreateJmods.gmk ! make/Docs.gmk ! make/GenerateLinkOptData.gmk ! make/GraalBuilderImage.gmk ! make/Images.gmk ! make/InitSupport.gmk ! make/JrtfsJar.gmk ! make/MacBundles.gmk ! make/ModuleWrapper.gmk ! make/SourceRevision.gmk ! make/StaticLibsImage.gmk ! make/autoconf/spec.gmk.template + make/common/FileUtils.gmk ! make/common/JarArchive.gmk ! make/common/JavaCompilation.gmk ! make/common/MakeBase.gmk ! make/common/MakeIO.gmk ! make/common/NativeCompilation.gmk ! make/common/Utils.gmk ! make/common/modules/CopyCommon.gmk ! make/common/modules/LauncherCommon.gmk ! make/hotspot/CopyToExplodedJdk.gmk ! make/hotspot/gensrc/GensrcJvmti.gmk ! make/hotspot/lib/CompileJvm.gmk ! make/hotspot/test/GtestImage.gmk ! make/modules/java.base/Lib.gmk ! make/modules/java.desktop/lib/Awt2dLibraries.gmk ! make/modules/jdk.compiler/Gendata.gmk ! make/test/BuildFailureHandler.gmk ! make/test/BuildJtregTestThreadFactory.gmk ! make/test/BuildMicrobenchmark.gmk ! make/test/BuildTestLib.gmk ! make/test/BuildTestLibNative.gmk ! make/test/JtregNativeHotspot.gmk ! make/test/JtregNativeJdk.gmk ! make/test/JtregNativeLibTest.gmk ! test/make/TestCopyFiles.gmk Changeset: 0656f080 Author: Guoxiong Li Date: 2024-04-11 15:01:41 +0000 URL: https://git.openjdk.org/leyden/commit/0656f0809208160f83a7dd1ae91d9f09b582ce35 8329469: Generational ZGC: Move the methods forwarding_[index|find|insert] from zRelocate.cpp to ZForwarding Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zForwarding.hpp ! src/hotspot/share/gc/z/zForwarding.inline.hpp ! src/hotspot/share/gc/z/zRelocate.cpp Changeset: 31ee5108 Author: Cesar Soares Lucas Committer: Martin Doerr Date: 2024-04-11 15:44:49 +0000 URL: https://git.openjdk.org/leyden/commit/31ee5108e059afae0a3809947adb7b91e19baec6 8241503: C2: Share MacroAssembler between mach nodes during code emission Reviewed-by: kvn, mdoerr, amitkumar, lucy ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_vector.ad ! src/hotspot/cpu/aarch64/aarch64_vector_ad.m4 ! src/hotspot/cpu/aarch64/ad_encode.m4 ! src/hotspot/cpu/aarch64/compiledIC_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoah_aarch64.ad ! src/hotspot/cpu/aarch64/gc/x/x_aarch64.ad ! src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/arm/compiledIC_arm.cpp ! src/hotspot/cpu/ppc/compiledIC_ppc.cpp ! src/hotspot/cpu/ppc/gc/shenandoah/shenandoah_ppc.ad ! src/hotspot/cpu/ppc/gc/x/x_ppc.ad ! src/hotspot/cpu/ppc/gc/z/z_ppc.ad ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/riscv/compiledIC_riscv.cpp ! src/hotspot/cpu/riscv/gc/shenandoah/shenandoah_riscv.ad ! src/hotspot/cpu/riscv/gc/x/x_riscv.ad ! src/hotspot/cpu/riscv/gc/z/z_riscv.ad ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/riscv_v.ad ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/cpu/s390/compiledIC_s390.cpp ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/c2_intelJccErratum_x86.cpp ! src/hotspot/cpu/x86/c2_intelJccErratum_x86.hpp ! src/hotspot/cpu/x86/compiledIC_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoah_x86_32.ad ! src/hotspot/cpu/x86/gc/shenandoah/shenandoah_x86_64.ad ! src/hotspot/cpu/x86/gc/x/xBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/x/x_x86_64.ad ! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/z/z_x86_64.ad ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad + src/hotspot/cpu/zero/c2_MacroAssembler_zero.hpp ! src/hotspot/cpu/zero/compiledIC_zero.cpp ! src/hotspot/share/adlc/adlparse.cpp ! src/hotspot/share/adlc/output_c.cpp ! src/hotspot/share/adlc/output_h.cpp ! src/hotspot/share/asm/assembler.hpp ! src/hotspot/share/code/compiledIC.hpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/opto/c2_CodeStubs.cpp ! src/hotspot/share/opto/c2_CodeStubs.hpp ! src/hotspot/share/opto/cfgnode.hpp ! src/hotspot/share/opto/constantTable.cpp ! src/hotspot/share/opto/constantTable.hpp ! src/hotspot/share/opto/locknode.hpp ! src/hotspot/share/opto/machnode.cpp ! src/hotspot/share/opto/machnode.hpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/opto/output.hpp Changeset: 5808f30b Author: Albert Mingkun Yang Date: 2024-04-11 19:22:11 +0000 URL: https://git.openjdk.org/leyden/commit/5808f30b89382af22027c43ebf14e36b0c16f041 8330026: Serial: Move some includes to vmStructs_serial.hpp Reviewed-by: kbarrett ! src/hotspot/share/gc/serial/vmStructs_serial.hpp ! src/hotspot/share/gc/shared/vmStructs_gc.hpp Changeset: 0db42906 Author: Jorn Vernee Date: 2024-04-11 20:54:09 +0000 URL: https://git.openjdk.org/leyden/commit/0db42906e390a98b3a6be078f1b8c3f2a03a838f 8330049: Remove unused AbstractLinker::linkerByteOrder Reviewed-by: mcimadamore ! src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64Linker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64Linker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/windows/WindowsAArch64Linker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FallbackLinker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64Linker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64leLinker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/riscv64/linux/LinuxRISCV64Linker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/LinuxS390Linker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVx64Linker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/Windowsx64Linker.java Changeset: ece7d434 Author: Matias Saavedra Silva Date: 2024-04-11 22:05:55 +0000 URL: https://git.openjdk.org/leyden/commit/ece7d4349a13f75c654e2ca0f4d1b66d3af5cf10 8329416: Split relocation pointer map into read-write and read-only maps Reviewed-by: iklam, ccheung ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveBuilder.hpp ! src/hotspot/share/cds/archiveHeapLoader.cpp ! src/hotspot/share/cds/archiveUtils.cpp ! src/hotspot/share/cds/archiveUtils.hpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp Changeset: e45fea5a Author: Axel Boldt-Christmas Date: 2024-04-12 06:04:20 +0000 URL: https://git.openjdk.org/leyden/commit/e45fea5a801ac09c3d572ac07d6179e80c422942 8329757: Crash with fatal error: DEBUG MESSAGE: Fast Unlock lock on stack Reviewed-by: pchilanomate, kvn ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/lockStack.cpp ! src/hotspot/share/runtime/lockStack.hpp + test/hotspot/jtreg/compiler/escapeAnalysis/Test8329757.java Changeset: bde3fc0c Author: Roland Westrelin Date: 2024-04-12 07:17:27 +0000 URL: https://git.openjdk.org/leyden/commit/bde3fc0c03c87d1f2605ae6bb84c33fadb7aa865 8330106: C2: VectorInsertNode::make() shouldn't call ConINode::make() directly Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp Changeset: 2c45eca1 Author: Thomas Schatzl Date: 2024-04-12 07:22:06 +0000 URL: https://git.openjdk.org/leyden/commit/2c45eca15943826cb6bfbdf6e6fd88abc196e8f7 8328879: G1: Some gtests modify global state crashing the JVM during GC after JDK-8289822 Reviewed-by: iwalulya, kbarrett ! test/hotspot/gtest/gc/g1/test_freeRegionList.cpp ! test/hotspot/gtest/gc/g1/test_heapRegion.cpp Changeset: 2c8b432b Author: Guoxiong Li Date: 2024-04-12 07:26:01 +0000 URL: https://git.openjdk.org/leyden/commit/2c8b432b8911bc1a52b02def89e4820c76ea67ba 8330003: Serial: Move the logic of FastEvacuateFollowersClosure to SerialHeap Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/gc/serial/serialHeap.inline.hpp Changeset: c7fcd623 Author: Guoxiong Li Date: 2024-04-12 07:29:41 +0000 URL: https://git.openjdk.org/leyden/commit/c7fcd62302a4b70214e4aea7052e661a2aa9b03b 8330006: Serial: Extract out ContiguousSpace::block_start_const Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/serial/cardTableRS.cpp ! src/hotspot/share/gc/serial/cardTableRS.hpp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/space.hpp Changeset: 006a516a Author: Albert Mingkun Yang Date: 2024-04-12 07:37:48 +0000 URL: https://git.openjdk.org/leyden/commit/006a516aa0e10d74ffafca2e2da2ae89faf47457 8329962: Remove CardTable::invalidate Reviewed-by: tschatzl, gli ! src/hotspot/share/gc/shared/cardTable.cpp ! src/hotspot/share/gc/shared/cardTable.hpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.cpp Changeset: aebfd53e Author: Ivan Walulya Date: 2024-04-12 07:46:43 +0000 URL: https://git.openjdk.org/leyden/commit/aebfd53e9d19f5939c81fa1a2fc75716c3355900 8329660: G1: Improve TestGCLogMessages to be more precise Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp ! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java Changeset: 717a07b9 Author: Tejesh R Date: 2024-04-12 10:21:31 +0000 URL: https://git.openjdk.org/leyden/commit/717a07b932e3dcabbad130d299b15cb963d50a67 8322140: javax/swing/JTable/JTableScrollPrintTest.java does not print the rows and columns of the table in Nimbus and Aqua LookAndFeel Reviewed-by: psadhukhan, abhiscxk ! src/java.desktop/share/classes/javax/swing/JViewport.java ! src/java.desktop/share/classes/sun/print/PathGraphics.java ! src/java.desktop/share/classes/sun/swing/SwingUtilities2.java ! test/jdk/javax/swing/JTable/JTableScrollPrintTest.java Changeset: 77a217df Author: Gui Cao Committer: Fei Yang Date: 2024-04-12 11:42:05 +0000 URL: https://git.openjdk.org/leyden/commit/77a217df6000190cf73a1ca42a42cbcec42fb60f 8330095: RISC-V: Remove obsolete vandn_vi instruction Reviewed-by: fyang, luhenry ! src/hotspot/cpu/riscv/assembler_riscv.hpp Changeset: 3e9c3811 Author: Coleen Phillimore Date: 2024-04-12 12:16:49 +0000 URL: https://git.openjdk.org/leyden/commit/3e9c3811669196945d7227affc28728670a256c5 8329488: Move OopStorage code from safepoint cleanup and remove safepoint cleanup code Reviewed-by: kbarrett, eosterlund ! src/hotspot/share/gc/shared/oopStorage.cpp ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/safepoint.hpp ! src/hotspot/share/runtime/serviceThread.cpp ! src/jdk.jfr/share/classes/jdk/jfr/internal/query/view.ini ! src/jdk.jfr/share/conf/jfr/default.jfc ! src/jdk.jfr/share/conf/jfr/profile.jfc ! test/hotspot/jtreg/gc/stress/TestReclaimStringsLeaksMemory.java - test/hotspot/jtreg/runtime/logging/SafepointCleanupTest.java ! test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java ! test/jdk/jdk/jfr/event/runtime/TestSafepointEvents.java ! test/lib/jdk/test/lib/jfr/EventNames.java Changeset: b8f675f4 Author: Guoxiong Li Date: 2024-04-12 12:54:36 +0000 URL: https://git.openjdk.org/leyden/commit/b8f675f45b890a9e969c250d9bf3117e6d61c2ff 8329771: G1: Refactor G1BlockOffsetTable::verify Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1HeapRegion.cpp Changeset: 0f78d017 Author: Guoxiong Li Date: 2024-04-12 12:59:49 +0000 URL: https://git.openjdk.org/leyden/commit/0f78d017afb786345fca635862a4a70f43fff251 8329658: Serial: Refactor ContiguousSpace::_next_compaction_space Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/serialFullGC.cpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/space.hpp Changeset: f7069494 Author: Guoxiong Li Date: 2024-04-12 14:06:07 +0000 URL: https://git.openjdk.org/leyden/commit/f7069494f4d292060834d0b7b7e92e5516a3001d 8329781: Serial: Remove serialFullGC.inline.hpp Reviewed-by: ayang, stefank, tschatzl ! src/hotspot/share/gc/serial/serialFullGC.cpp ! src/hotspot/share/gc/serial/serialFullGC.hpp - src/hotspot/share/gc/serial/serialFullGC.inline.hpp Changeset: 397d9483 Author: Matthias Baesken Date: 2024-04-12 14:09:23 +0000 URL: https://git.openjdk.org/leyden/commit/397d94831033e91c7a849774bf4e80d8f1c8ec66 8329605: hs errfile generic events - move memory protections and nmethod flushes to separate sections Reviewed-by: lucy, stefank, stuefe ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/utilities/events.cpp ! src/hotspot/share/utilities/events.hpp Changeset: 68f86dcc Author: Magnus Ihse Bursie Date: 2024-04-12 20:57:56 +0000 URL: https://git.openjdk.org/leyden/commit/68f86dccce601ec10111dc3e535d28ce9fc80928 8330110: AIX build fails after JDK-8329704 - issue with libjli.a Reviewed-by: mbaesken, mdoerr ! make/common/JdkNativeCompilation.gmk Changeset: 28b20195 Author: Alex Menkov Date: 2024-04-12 22:29:34 +0000 URL: https://git.openjdk.org/leyden/commit/28b201955907e145f208d756b607ab545a83b2d3 8240343: JDI stopListening/stoplis001 "FAILED: listening is successfully stopped without starting listening" Reviewed-by: cjplummer, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/stopListening/stoplis001.java - test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/stopListening/stoplis001/TEST.properties ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/stopListening/stoplis001/TestDescription.java Changeset: b9ef9f66 Author: Scott Gibbons Committer: Vladimir Kozlov Date: 2024-04-13 00:48:52 +0000 URL: https://git.openjdk.org/leyden/commit/b9ef9f667ef9d4052c9d6dfec763b94d331dc04d 8330185: Potential uncaught unsafe memory copy exception Reviewed-by: kvn, sviswanathan ! src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp Changeset: c1c99a66 Author: Serguei Spitsyn Date: 2024-04-13 09:22:00 +0000 URL: https://git.openjdk.org/leyden/commit/c1c99a669bb7f9928086db6a4ecfc90c410ffbb0 8329674: JvmtiEnvThreadState::reset_current_location function should use JvmtiHandshake Reviewed-by: lmesnik, pchilanomate ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiEnvThreadState.cpp ! src/hotspot/share/runtime/vmOperation.hpp Changeset: 1abb8262 Author: Leonid Mesnik Date: 2024-04-14 16:02:07 +0000 URL: https://git.openjdk.org/leyden/commit/1abb826210eda76a3dc8cf1c10e6df6f2413a87a 8330131: Problemlist serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java Reviewed-by: dcubed ! test/hotspot/jtreg/ProblemList.txt Changeset: b486709b Author: Christian Hagedorn Date: 2024-04-15 06:25:24 +0000 URL: https://git.openjdk.org/leyden/commit/b486709b0627cfb4cf428a6508ef7c5b14e6da57 8328480: C2: SubTypeCheckNode in checkcast should use the klass constant of a unique concrete sub class Reviewed-by: roland, kvn ! src/hotspot/share/opto/graphKit.cpp + test/hotspot/jtreg/compiler/types/TestSubTypeCheckUniqueSubclass.java Changeset: bc1a1a58 Author: David Holmes Date: 2024-04-15 07:31:58 +0000 URL: https://git.openjdk.org/leyden/commit/bc1a1a5861741ce5002e28eed2ea84ddafd68c70 8330064: JFR: Incorrect function declarations for register/unregister_stack_filter Reviewed-by: mgronlun, dcubed, egahlin, jwaters ! src/hotspot/share/jfr/jni/jfrJniMethod.hpp Changeset: d22d5608 Author: David Holmes Date: 2024-04-15 07:33:10 +0000 URL: https://git.openjdk.org/leyden/commit/d22d56087142d2fdf8ffc5fcde83dd08f07f6933 8329864: TestLibGraal.java still crashes with assert(_stack_base != nullptr) Reviewed-by: dnsimon, jsjolen, dcubed ! src/hotspot/share/runtime/javaThread.cpp Changeset: 5404b4ea Author: Yudi Zheng Committer: Doug Simon Date: 2024-04-15 08:07:49 +0000 URL: https://git.openjdk.org/leyden/commit/5404b4eafc2eb3291cecf99f98728946388f5d16 8330105: SharedRuntime::resolve* should respect interpreter-only mode Reviewed-by: never, dlong, dnsimon ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp Changeset: 3f1d9c44 Author: Joachim Kern Committer: Martin Doerr Date: 2024-04-15 08:46:36 +0000 URL: https://git.openjdk.org/leyden/commit/3f1d9c441ea98910d9483e133bccfac784db393d 8329257: AIX: Switch HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc Reviewed-by: jwaters, stuefe, kbarrett, mdoerr ! make/autoconf/flags-cflags.m4 ! make/autoconf/toolchain.m4 ! src/hotspot/os/aix/loadlib_aix.cpp ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/aix/os_aix.hpp ! src/hotspot/os/aix/porting_aix.cpp ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp ! src/hotspot/share/utilities/byteswap.hpp - src/hotspot/share/utilities/compilerWarnings_xlc.hpp ! src/hotspot/share/utilities/count_leading_zeros.hpp ! src/hotspot/share/utilities/count_trailing_zeros.hpp ! src/hotspot/share/utilities/debug.hpp ! src/hotspot/share/utilities/globalDefinitions_gcc.hpp - src/hotspot/share/utilities/globalDefinitions_xlc.hpp Changeset: 60d88b7a Author: Per Minborg Date: 2024-04-15 12:42:31 +0000 URL: https://git.openjdk.org/leyden/commit/60d88b7ae2945724ab4db44207e3390bcff172c0 8330176: Typo in Linker javadoc Reviewed-by: mcimadamore ! src/java.base/share/classes/java/lang/foreign/Linker.java Changeset: a3fecdb2 Author: Thomas Schatzl Date: 2024-04-15 13:21:18 +0000 URL: https://git.openjdk.org/leyden/commit/a3fecdb2f417bd32e528f907bc293cc494746955 8329764: G1: Handle null references during verification first Reviewed-by: stefank, iwalulya ! src/hotspot/share/gc/g1/g1HeapRegion.cpp Changeset: 273df628 Author: Albert Mingkun Yang Date: 2024-04-15 13:32:26 +0000 URL: https://git.openjdk.org/leyden/commit/273df6286a9cc4dcef4cd339234206b2ad922386 8328792: Parallel: Refactor PSParallelCompact::summary_phase Reviewed-by: iwalulya, tschatzl ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp Changeset: ddc3921c Author: Thomas Stuefe Date: 2024-04-15 15:01:05 +0000 URL: https://git.openjdk.org/leyden/commit/ddc3921cf98b9470f597ae9bb6a4f5a043e1544f 8330103: Compiler memory statistics should keep separate records for C1 and C2 Reviewed-by: kvn, redestad ! src/hotspot/share/compiler/compilationMemoryStatistic.cpp Changeset: da75e015 Author: Joe Darcy Date: 2024-04-15 15:11:40 +0000 URL: https://git.openjdk.org/leyden/commit/da75e015b54f4ff011837995cacf80850411bb74 8330196: Make java/lang/invoke/defineHiddenClass/BasicTest release agnostic Reviewed-by: liach, mchung, jkuhn ! test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java Changeset: a293bdff Author: Joe Darcy Date: 2024-04-15 15:11:53 +0000 URL: https://git.openjdk.org/leyden/commit/a293bdff91f7bcc0deece6bed3151a40fad42a64 8330197: Make javac/diags/example release agnostic Reviewed-by: jlahoda ! test/langtools/tools/javac/diags/examples/DefaultAndBothBoolean.java ! test/langtools/tools/javac/diags/examples/UnconditionalPatternAndBothBoolean.java Changeset: 140f5671 Author: Joshua Cao Committer: Emanuel Peter Date: 2024-04-15 15:54:34 +0000 URL: https://git.openjdk.org/leyden/commit/140f56718bbbfc31bb0c39255c68568fad285a1f 8323220: Reassociate loop invariants involved in Cmps and Add/Subs Reviewed-by: epeter, xliu, chagedorn ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.hpp + test/hotspot/jtreg/compiler/loopopts/InvariantCodeMotionReassociateAddSub.java + test/hotspot/jtreg/compiler/loopopts/InvariantCodeMotionReassociateCmp.java Changeset: 274c805c Author: David Holmes Date: 2024-04-16 00:48:15 +0000 URL: https://git.openjdk.org/leyden/commit/274c805c5137d9080a7670d864ecca8a0befc3f6 8327743: JVM crash in hotspot/share/runtime/javaThread.cpp - failed: held monitor count should be equal to jni: 0 != 1 Co-authored-by: Fredrik Bredberg Reviewed-by: rehn, fbredberg, pchilanomate, rrich ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! test/hotspot/jtreg/runtime/vthread/JNIMonitor/JNIMonitor.java ! test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java Changeset: 31a1f9c4 Author: Weijun Wang Date: 2024-04-16 01:03:14 +0000 URL: https://git.openjdk.org/leyden/commit/31a1f9c493764615acfba7392d8e3578b793abab 8307143: CredentialsCache.cacheName should not be static Reviewed-by: valeriep ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/CredentialsCache.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java - src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/MemoryCredentialsCache.java ! src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java + test/jdk/sun/security/krb5/ccache/TwoFiles.java Changeset: 2f11afda Author: Guoxiong Li Date: 2024-04-16 06:19:32 +0000 URL: https://git.openjdk.org/leyden/commit/2f11afdae93d47da2bc9036ea109f34f09d28c7e 8330172: G1: Consolidate update_bot_for_block and update_bot_for_obj in HeapRegion Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1HeapRegion.cpp ! src/hotspot/share/gc/g1/g1HeapRegion.hpp ! src/hotspot/share/gc/g1/g1HeapRegion.inline.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp Changeset: def25772 Author: Markus Gr?nlund Date: 2024-04-16 06:51:37 +0000 URL: https://git.openjdk.org/leyden/commit/def257727dd19b2bf11e8afa18d741d3502331ae 8330215: Trim working set for OldObjectSamples Reviewed-by: jbachorik, egahlin ! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp ! src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp ! src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.hpp ! src/hotspot/share/jfr/utilities/jfrSignal.hpp Changeset: 97c18089 Author: Adam Sotona Date: 2024-04-16 08:23:31 +0000 URL: https://git.openjdk.org/leyden/commit/97c180892b62ccba0041fb4480ecd2191aea0032 8329099: Undocumented exception thrown by Instruction factory methods accepting Opcode Reviewed-by: briangoetz ! src/java.base/share/classes/java/lang/classfile/instruction/ArrayLoadInstruction.java ! src/java.base/share/classes/java/lang/classfile/instruction/ArrayStoreInstruction.java ! src/java.base/share/classes/java/lang/classfile/instruction/BranchInstruction.java ! src/java.base/share/classes/java/lang/classfile/instruction/ConstantInstruction.java ! src/java.base/share/classes/java/lang/classfile/instruction/ConvertInstruction.java ! src/java.base/share/classes/java/lang/classfile/instruction/DiscontinuedInstruction.java ! src/java.base/share/classes/java/lang/classfile/instruction/FieldInstruction.java ! src/java.base/share/classes/java/lang/classfile/instruction/InvokeInstruction.java ! src/java.base/share/classes/java/lang/classfile/instruction/LoadInstruction.java ! src/java.base/share/classes/java/lang/classfile/instruction/MonitorInstruction.java ! src/java.base/share/classes/java/lang/classfile/instruction/NewPrimitiveArrayInstruction.java ! src/java.base/share/classes/java/lang/classfile/instruction/OperatorInstruction.java ! src/java.base/share/classes/java/lang/classfile/instruction/ReturnInstruction.java ! src/java.base/share/classes/java/lang/classfile/instruction/StackInstruction.java ! src/java.base/share/classes/java/lang/classfile/instruction/StoreInstruction.java ! src/java.base/share/classes/java/lang/classfile/instruction/TypeCheckInstruction.java ! src/java.base/share/classes/java/lang/classfile/package-info.java Changeset: 58911ccc Author: Kevin Walls Date: 2024-04-16 10:20:50 +0000 URL: https://git.openjdk.org/leyden/commit/58911ccc2c48b4b5dd2ebc9d2a44dcf3737eca50 8188784: javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST FAILED: deadlock Reviewed-by: cjplummer, lmesnik ! test/jdk/javax/management/notification/BroadcasterSupportDeadlockTest.java Changeset: 8a5b86c5 Author: Viktor Klang Date: 2024-04-16 11:09:59 +0000 URL: https://git.openjdk.org/leyden/commit/8a5b86c52954f6917acfda11df183691beb07f56 8196106: Support nested infinite or recursive flat mapped streams Reviewed-by: psandoz ! src/java.base/share/classes/java/util/stream/AbstractPipeline.java ! src/java.base/share/classes/java/util/stream/DoublePipeline.java ! src/java.base/share/classes/java/util/stream/GathererOp.java ! src/java.base/share/classes/java/util/stream/IntPipeline.java ! src/java.base/share/classes/java/util/stream/LongPipeline.java ! src/java.base/share/classes/java/util/stream/ReferencePipeline.java ! test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java + test/micro/org/openjdk/bench/java/util/stream/ops/DoubleAccumulator.java + test/micro/org/openjdk/bench/java/util/stream/ops/ref/FlatMap.java Changeset: 56ff87a0 Author: Albert Mingkun Yang Date: 2024-04-16 13:51:04 +0000 URL: https://git.openjdk.org/leyden/commit/56ff87a09648ed6bb1176a28f70982d9241627a2 8330359: G1: Remove unused forward declaration in g1BlockOffsetTable.hpp Reviewed-by: iwalulya, gli ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp Changeset: 61fa4d45 Author: Magnus Ihse Bursie Date: 2024-04-16 13:51:14 +0000 URL: https://git.openjdk.org/leyden/commit/61fa4d45b68ffbfb751471730518651b78b195aa 8330351: Remove the SHARED_LIBRARY and STATIC_LIBRARY macros Reviewed-by: erikj ! make/RunTestsPrebuiltSpec.gmk ! make/autoconf/spec.gmk.template ! make/autoconf/toolchain.m4 ! make/hotspot/test/GtestImage.gmk ! make/modules/java.base/Lib.gmk Changeset: 6e77d918 Author: Magnus Ihse Bursie Date: 2024-04-16 13:52:16 +0000 URL: https://git.openjdk.org/leyden/commit/6e77d918e62a2eb77c3c1cc32b8ddad909036517 8330261: Clean up linking steps Reviewed-by: erikj ! make/autoconf/jdk-options.m4 ! make/common/NativeCompilation.gmk ! make/common/native/DebugSymbols.gmk ! make/common/native/Link.gmk ! make/common/native/LinkMicrosoft.gmk Changeset: e073d5b3 Author: Patricio Chilano Mateo Date: 2024-04-16 14:09:44 +0000 URL: https://git.openjdk.org/leyden/commit/e073d5b37422c2adad18db520c5f4fcf120c147b 8329665: fatal error: memory leak: allocating without ResourceMark Reviewed-by: dholmes, shade, coleenp ! src/hotspot/share/interpreter/oopMapCache.cpp ! src/hotspot/share/interpreter/oopMapCache.hpp ! src/hotspot/share/runtime/frame.cpp Changeset: bfff02ee Author: Roland Westrelin Date: 2024-04-16 14:11:05 +0000 URL: https://git.openjdk.org/leyden/commit/bfff02eef68c80f623419a3f6ceb9fe3121b88f4 8330165: C2: make superword consistently use PhaseIdealLoop::register_new_node() Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/split_if.cpp ! src/hotspot/share/opto/superword.cpp Changeset: f11a496d Author: Andrew Haley Date: 2024-04-16 14:21:48 +0000 URL: https://git.openjdk.org/leyden/commit/f11a496de61d800a680517457eb43b078a633953 8180450: secondary_super_cache does not scale well Co-authored-by: Vladimir Ivanov Reviewed-by: kvn, vlivanov, dlong ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.hpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/oops/arrayKlass.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/oops/objArrayKlass.cpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/matcher.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/runtime/abstract_vm_version.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/stubRoutines.cpp ! src/hotspot/share/runtime/stubRoutines.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp + src/hotspot/share/utilities/rotate_bits.hpp + test/micro/org/openjdk/bench/vm/compiler/SecondarySuperCacheHits.java + test/micro/org/openjdk/bench/vm/compiler/SecondarySuperCacheInterContention.java + test/micro/org/openjdk/bench/vm/compiler/SecondarySuperCacheIntraContention.java + test/micro/org/openjdk/bench/vm/lang/SecondarySupersLookup.java + test/micro/org/openjdk/bench/vm/lang/TypePollution.java Changeset: c9feeb6f Author: iklam Date: 2024-04-16 20:13:02 +0000 URL: https://git.openjdk.org/leyden/commit/c9feeb6f6fd883124bd79c59a9ab8df841d7fb5e Merge branch 'master' of https://github.com/openjdk/leyden into premain ! make/InitSupport.gmk ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveBuilder.hpp ! src/hotspot/share/cds/archiveHeapLoader.cpp ! src/hotspot/share/cds/archiveHeapWriter.cpp ! src/hotspot/share/cds/archiveHeapWriter.hpp ! src/hotspot/share/cds/archiveUtils.cpp ! src/hotspot/share/cds/archiveUtils.hpp ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/cds/methodProfiler.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/code/SCCache.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/linkResolver.hpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/oops/oop.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/threads.cpp ! src/hotspot/share/runtime/threads.hpp ! make/InitSupport.gmk ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveBuilder.hpp ! src/hotspot/share/cds/archiveHeapLoader.cpp ! src/hotspot/share/cds/archiveHeapWriter.cpp ! src/hotspot/share/cds/archiveHeapWriter.hpp ! src/hotspot/share/cds/archiveUtils.cpp ! src/hotspot/share/cds/archiveUtils.hpp ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp + src/hotspot/share/cds/methodProfiler.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/systemDictionary.cpp + src/hotspot/share/code/SCCache.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/linkResolver.hpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/oops/oop.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/threads.cpp ! src/hotspot/share/runtime/threads.hpp From duke at openjdk.org Wed Apr 17 06:24:38 2024 From: duke at openjdk.org (duke) Date: Wed, 17 Apr 2024 06:24:38 GMT Subject: git: openjdk/leyden: premain: Allocate all TD in the null class loader data Message-ID: <58c995dd-941d-41ac-a196-060a2beb5239@openjdk.org> Changeset: 2e3f59b9 Author: Igor Veresov Date: 2024-04-16 23:00:47 +0000 URL: https://git.openjdk.org/leyden/commit/2e3f59b95edf1230eeb16d18dd601de59249613c Allocate all TD in the null class loader data ! src/hotspot/share/oops/trainingData.cpp From magnus.ihse.bursie at oracle.com Wed Apr 17 09:55:05 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 17 Apr 2024 11:55:05 +0200 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> Message-ID: <5b35878b-6413-4e3f-b9e3-a9b761516c99@oracle.com> On 2024-04-16 07:23, Julian Waters wrote: >> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. > objcopy is also available on Windows, if the question about > alternative tooling is still unanswered :) At this point, I think support for static build on Windows is to either require additional tooling on top of the Microsoft Visual Studio toolchain, or to drop it completely, so I am definitely interested in researching alternatives. Can objcopy (I assume this is from msys?) deal with COFF files generated by cl? Switching the entire toolchain is not relevant at this point (but if a non-Microsoft toolchain build for Windows is ever integrated, it might get static builds with no extra work as a bonus), but I could certainly accept the idea of having one or a few additional tools required to get the normal Microsoft toolchain to produce static builds. /Magnus > > best regards, > Julian > > On Fri, Apr 12, 2024 at 7:52?PM Magnus Ihse Bursie > wrote: >> On 2024-04-02 21:16, Jiangli Zhou wrote: >> >> Hi Magnus, >> >> In today's zoom meeting with Alan, Ron, Liam and Chuck, we (briefly) discussed how to move forward contributing the static Java related changes (additional runtime fixes/enhancements on top of the existing static support in JDK) from https://github.com/openjdk/leyden/tree/hermetic-java-runtime to JDK mainline. >> >> Just a bit more details/context below, which may be useful for others reading this thread. >> >> The https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch currently contains following for supporting hermetic Java (without the launcher work for runtime support): >> >> 1. Build change for linking the Java launcher (as bin/javastatic) with JDK/hotspot static libraries (.a), mainly in https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk. The part for creating the complete sets of static libraries (including libjvm.a) has already been included in the mainline since last year. https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk is in a very raw state and is intended to demonstrate the capability of building a static Java launcher. >> >> Indeed. It is nowhere near being able to be integrated. >> >> >> 2. Additional runtime fixes/enhancements on top of the existing static support in JDK, e.g. support further lookup dynamic native library if the built-in native library cannot be found. >> >> 3. Some initial (prototype) work on supporting hermetic JDK resource files in the jimage (JDK modules image). >> >> To move forward, one of the earliest items needed is to add the capability of building the fully statically linked Java launcher in JDK mainline. The other static Java runtime changes can be followed up after the launcher linking part, so they can be built and tested as individual PRs created for the JDK mainline. Magnus, you have expressed interest in helping get the launcher linking part (refactor from https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk) into JDK mainline. What's your thought on prioritizing the launcher static linking part before other makefile clean ups for static libraries? >> >> Trust me, my absolute top priority now is working on getting the proper build support needed for Hermetic Java. I can't prioritize it any higher. >> >> I am not sure what you are asking for. We can't just merge StaticLink.gmk from your prototype. And even if we did, what good will it do you? >> >> The problem you are running into is that the build system has not been designed to properly support static linking. There are already 3-4 hacks in place to get something sort-of useful out, but they are prone to breaking. I assume that we agree that for Hermetic Java to become a success, we need to have a stable foundation for static builds. >> >> The core problem of all static linking hacks is that they are not integrated in the right place. They need to be a core part of what NativeCompilation delivers, not something done in a separate file. To put it in other words, StaticLink.gmk from your branch do not need cleanup -- it needs to go away, and the functionality moved to the proper place. >> >> My approach is that NativeCompilation should support doing either only dynamic linking (as today), or static linking (as today with STATIC_LIBS or STATIC_BUILD), or both. The assumption is that the latter will be default, or at least should be tested by default in GHA. For this to work, we need to compile the source code to .o files only once, and then link these .o files either into a dynamic or a static library (or both). >> >> This, in turn, require several changes: >> >> 1) The linking code needs to be cleaned up, and all technical debt needs to be resolved. This is what I have been doing since I started working on static builds for Hermetic Java. JDK-8329704 (which was integrated yesterday) was the first major milestone of this cleanup. Now, the path were to find a library created by the JDK (static or dynamic) is encapsulated in ResolveLibPath. This is currently a monster, but at least all knowledge is collected in a single location, instead of spread over the code base. Getting this simplified is the next step. >> >> 2) We need to stop passing the STATIC_BUILD define when compiling. This is partially addressed in your PR, where you have replaced #ifdef STATIC_BUILD with a dynamic lookup. But there is also the problem of JNI/JVMTI entry points. I have been pondering how we can compile the code in a way so we support both dynamic and static name resolution, and I think I have a solution. >> >> This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. >> >> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. >> >> A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. >> >> My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. >> >> /Magnus >> >> >> >> Thanks! >> Jiangli >> >> On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: >>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: >>>> Hi Magnus, >>>> >>>> Thanks for looking into this from the build perspective. >>>> >>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie >>>> wrote: >>>>> 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. >>>> Some additional hermetic Java related references that are also useful: >>>> >>>> - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that >>>> links to the issues for resolving static linking issues so far >>>> - https://github.com/openjdk/jdk21/pull/26 is the enhancement for >>>> building the complete set of static libraries in JDK/VM, particularly >>>> including libjvm.a >>>> >>>>> 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? >>>> I have a similar view as Alan responded in your other email thread. >>>> Things are still in the early stage for the general solution. >>>> >>>> In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime >>>> branch, when configuring JDK with --with-static-java=yes, the JDK >>>> binary contains the following extra artifacts: >>>> >>>> - static-libs/*.a: The complete set of JDK/VM static libraries >>>> - jdk/bin/javastatic: A demo Java launcher fully statically linked >>>> with the selected JDK .a libraries (e.g. it currently statically link >>>> with the headless) and libjvm.a. It's the standard Java launcher >>>> without additional work for hermetic Java. >>>> >>>> In our prototype for hermetic Java, we build the hermetic executable >>>> image (a single image) from the following input (see description on >>>> singlejar packaging tool in >>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf): >>>> >>>> - A customized launcher (with additional work for hermetic) executable >>>> fully statically linked with JDK/VM static libraries (.a files), >>>> application natives and dependencies (e.g. in .a static libraries) >>>> - JDK lib/modules, JDK resource files >>>> - Application classes and resource files >>>> >>>> Including a JDK library .a into the corresponding .jmod would require >>>> extracting the .a for linking with the executable. In some systems >>>> that may cause memory overhead due to the extracted copy of the .a >>>> files. I think we should consider the memory overhead issue. >>>> >>>> One possibility (as Alan described in his response) is for jlink to >>>> invoke the ld on the build system. jlink could pass the needed JDK >>>> static libraries and libjvm.a (provided as part of the JDK binary) to >>>> ld based on the modules required for the application. >>>> >>> I gave a bit more thoughts on this one. For jlink to trigger ld, it >>> would need to know the complete linker options and inputs. Those >>> include options and inputs related to the application part as well. In >>> some usages, it might be easier to handle native linking separately >>> and pass the linker output, the executable to jlink directly. Maybe we >>> could consider supporting different modes for various usages >>> requirements, from static libraries and native linking point of view: >>> >>> Mode #1 >>> Support .jmod packaged natives static libraries, for both JDK/VM .a >>> and application natives and dependencies. If the inputs to jlink >>> include .jmods, jlink can extract the .a libraries and pass the >>> information to ld to link the executable. >>> >>> Mode #2 >>> Support separate .a as jlink input. Jlink could pass the path >>> information to the .a libraries and other linker options to ld to >>> create the executable. >>> >>> For both mode #1 and #2, jlink would then use the linker output >>> executable to create the final hermetic image. >>> >>> Mode #3 >>> Support a fully linked executable as a jlink input. When a linked >>> executable is given to jlink, it can process it directly with other >>> JDK data/files to create the final image, without native linking step. >>> >>> Any other thoughts and considerations? >>> >>> Best, >>> Jiangli >>> >>>>> 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. >>>> An alternative with less memory overhead could be using application >>>> modular JAR and separate .a as the input for jlink. >>>> >>>>> 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. >>>> Part of the current effort includes resolving the discovered symbol >>>> collision issues with static linking. Will respond to your other email >>>> on the symbol issue separately later. >>>> >>>>> 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. >>>> I think we would need both configure flag and special target for the >>>> static builds. >>>> >>>>> 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. >>>> For the potential objcopy work to resolve symbol issues, we can add >>>> that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We >>>> have an internal prototype (not included in >>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done >>>> by one of colleagues for localizing symbols in libfreetype using >>>> objcopy. >>>> >>>>> 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". >>>> If we want to also build a fully statically linked launcher, maybe >>>> --with-static-java? Being able to configure either dynamic, static or >>>> both as you suggested also seems to be a good idea. >>>> >>>>> 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. >>>> Completely agree. It would be good to avoid recompiling the .o file >>>> for static and dynamic builds. As proposed in >>>> https://bugs.openjdk.org/browse/JDK-8303796: >>>> >>>> It's beneficial to be able to build both .so and .a from the same set >>>> of .o files. That would involve some changes to handle the dynamic JDK >>>> and static JDK difference at runtime, instead of relying on the >>>> STATIC_BUILD macro. >>>> >>>>> 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. >>>> Renaming or redefining the symbol at build time could cause confusions >>>> with debugging. That's a concern raised in >>>> https://github.com/openjdk/jdk/pull/17456 discussions. >>>> >>>> Additionally, redefining symbols using tools like objcopy may not >>>> handle member names referenced in string literals. For example, in >>>> https://github.com/openjdk/jdk/pull/17456 additional changes are >>>> needed in assembling and SA to reflect the symbol change. >>>> >>>>> 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? >>>> We have done some testing with jtreg SA related tests for the fully >>>> statically linked `javastatic`. >>>> >>>> If we use objcopy to localize symbols in hotspot, it's not yet clear >>>> what's the impact on SA. We could do some tests. The other question >>>> that I raised is the supported gcc versions (for partial linking) >>>> related to the solution. >>>> >>>> Best, >>>> Jiangli >>>> >>>>> /Magnus >>>>> From tanksherman27 at gmail.com Wed Apr 17 12:06:44 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Wed, 17 Apr 2024 20:06:44 +0800 Subject: Questions about the Hermetic Java project In-Reply-To: <5b35878b-6413-4e3f-b9e3-a9b761516c99@oracle.com> References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <5b35878b-6413-4e3f-b9e3-a9b761516c99@oracle.com> Message-ID: Hi Magnus, Yes, I'm talking about the MSYS2 objcopy, but to a lesser extent also standalone Windows objcopy builds too. objcopy should be able to handle .o files from cl.exe (I assume that's what everyone here is after considering all the talk about .o files?), but to answer that question properly, I'd need a bit more detail. What kind of usage of objcopy do you have in mind? A general-ish command line example could be helpful best regards, Julian On Wed, Apr 17, 2024 at 5:55?PM Magnus Ihse Bursie wrote: > > On 2024-04-16 07:23, Julian Waters wrote: > > >> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. > > objcopy is also available on Windows, if the question about > > alternative tooling is still unanswered :) > > At this point, I think support for static build on Windows is to either > require additional tooling on top of the Microsoft Visual Studio > toolchain, or to drop it completely, so I am definitely interested in > researching alternatives. > > Can objcopy (I assume this is from msys?) deal with COFF files generated > by cl? > > Switching the entire toolchain is not relevant at this point (but if a > non-Microsoft toolchain build for Windows is ever integrated, it might > get static builds with no extra work as a bonus), but I could certainly > accept the idea of having one or a few additional tools required to get > the normal Microsoft toolchain to produce static builds. > > /Magnus > > > > > best regards, > > Julian > > > > On Fri, Apr 12, 2024 at 7:52?PM Magnus Ihse Bursie > > wrote: > >> On 2024-04-02 21:16, Jiangli Zhou wrote: > >> > >> Hi Magnus, > >> > >> In today's zoom meeting with Alan, Ron, Liam and Chuck, we (briefly) discussed how to move forward contributing the static Java related changes (additional runtime fixes/enhancements on top of the existing static support in JDK) from https://github.com/openjdk/leyden/tree/hermetic-java-runtime to JDK mainline. > >> > >> Just a bit more details/context below, which may be useful for others reading this thread. > >> > >> The https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch currently contains following for supporting hermetic Java (without the launcher work for runtime support): > >> > >> 1. Build change for linking the Java launcher (as bin/javastatic) with JDK/hotspot static libraries (.a), mainly in https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk. The part for creating the complete sets of static libraries (including libjvm.a) has already been included in the mainline since last year. https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk is in a very raw state and is intended to demonstrate the capability of building a static Java launcher. > >> > >> Indeed. It is nowhere near being able to be integrated. > >> > >> > >> 2. Additional runtime fixes/enhancements on top of the existing static support in JDK, e.g. support further lookup dynamic native library if the built-in native library cannot be found. > >> > >> 3. Some initial (prototype) work on supporting hermetic JDK resource files in the jimage (JDK modules image). > >> > >> To move forward, one of the earliest items needed is to add the capability of building the fully statically linked Java launcher in JDK mainline. The other static Java runtime changes can be followed up after the launcher linking part, so they can be built and tested as individual PRs created for the JDK mainline. Magnus, you have expressed interest in helping get the launcher linking part (refactor from https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk) into JDK mainline. What's your thought on prioritizing the launcher static linking part before other makefile clean ups for static libraries? > >> > >> Trust me, my absolute top priority now is working on getting the proper build support needed for Hermetic Java. I can't prioritize it any higher. > >> > >> I am not sure what you are asking for. We can't just merge StaticLink.gmk from your prototype. And even if we did, what good will it do you? > >> > >> The problem you are running into is that the build system has not been designed to properly support static linking. There are already 3-4 hacks in place to get something sort-of useful out, but they are prone to breaking. I assume that we agree that for Hermetic Java to become a success, we need to have a stable foundation for static builds. > >> > >> The core problem of all static linking hacks is that they are not integrated in the right place. They need to be a core part of what NativeCompilation delivers, not something done in a separate file. To put it in other words, StaticLink.gmk from your branch do not need cleanup -- it needs to go away, and the functionality moved to the proper place. > >> > >> My approach is that NativeCompilation should support doing either only dynamic linking (as today), or static linking (as today with STATIC_LIBS or STATIC_BUILD), or both. The assumption is that the latter will be default, or at least should be tested by default in GHA. For this to work, we need to compile the source code to .o files only once, and then link these .o files either into a dynamic or a static library (or both). > >> > >> This, in turn, require several changes: > >> > >> 1) The linking code needs to be cleaned up, and all technical debt needs to be resolved. This is what I have been doing since I started working on static builds for Hermetic Java. JDK-8329704 (which was integrated yesterday) was the first major milestone of this cleanup. Now, the path were to find a library created by the JDK (static or dynamic) is encapsulated in ResolveLibPath. This is currently a monster, but at least all knowledge is collected in a single location, instead of spread over the code base. Getting this simplified is the next step. > >> > >> 2) We need to stop passing the STATIC_BUILD define when compiling. This is partially addressed in your PR, where you have replaced #ifdef STATIC_BUILD with a dynamic lookup. But there is also the problem of JNI/JVMTI entry points. I have been pondering how we can compile the code in a way so we support both dynamic and static name resolution, and I think I have a solution. > >> > >> This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. > >> > >> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. > >> > >> A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. > >> > >> My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. > >> > >> /Magnus > >> > >> > >> > >> Thanks! > >> Jiangli > >> > >> On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: > >>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: > >>>> Hi Magnus, > >>>> > >>>> Thanks for looking into this from the build perspective. > >>>> > >>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie > >>>> wrote: > >>>>> 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. > >>>> Some additional hermetic Java related references that are also useful: > >>>> > >>>> - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that > >>>> links to the issues for resolving static linking issues so far > >>>> - https://github.com/openjdk/jdk21/pull/26 is the enhancement for > >>>> building the complete set of static libraries in JDK/VM, particularly > >>>> including libjvm.a > >>>> > >>>>> 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? > >>>> I have a similar view as Alan responded in your other email thread. > >>>> Things are still in the early stage for the general solution. > >>>> > >>>> In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime > >>>> branch, when configuring JDK with --with-static-java=yes, the JDK > >>>> binary contains the following extra artifacts: > >>>> > >>>> - static-libs/*.a: The complete set of JDK/VM static libraries > >>>> - jdk/bin/javastatic: A demo Java launcher fully statically linked > >>>> with the selected JDK .a libraries (e.g. it currently statically link > >>>> with the headless) and libjvm.a. It's the standard Java launcher > >>>> without additional work for hermetic Java. > >>>> > >>>> In our prototype for hermetic Java, we build the hermetic executable > >>>> image (a single image) from the following input (see description on > >>>> singlejar packaging tool in > >>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf): > >>>> > >>>> - A customized launcher (with additional work for hermetic) executable > >>>> fully statically linked with JDK/VM static libraries (.a files), > >>>> application natives and dependencies (e.g. in .a static libraries) > >>>> - JDK lib/modules, JDK resource files > >>>> - Application classes and resource files > >>>> > >>>> Including a JDK library .a into the corresponding .jmod would require > >>>> extracting the .a for linking with the executable. In some systems > >>>> that may cause memory overhead due to the extracted copy of the .a > >>>> files. I think we should consider the memory overhead issue. > >>>> > >>>> One possibility (as Alan described in his response) is for jlink to > >>>> invoke the ld on the build system. jlink could pass the needed JDK > >>>> static libraries and libjvm.a (provided as part of the JDK binary) to > >>>> ld based on the modules required for the application. > >>>> > >>> I gave a bit more thoughts on this one. For jlink to trigger ld, it > >>> would need to know the complete linker options and inputs. Those > >>> include options and inputs related to the application part as well. In > >>> some usages, it might be easier to handle native linking separately > >>> and pass the linker output, the executable to jlink directly. Maybe we > >>> could consider supporting different modes for various usages > >>> requirements, from static libraries and native linking point of view: > >>> > >>> Mode #1 > >>> Support .jmod packaged natives static libraries, for both JDK/VM .a > >>> and application natives and dependencies. If the inputs to jlink > >>> include .jmods, jlink can extract the .a libraries and pass the > >>> information to ld to link the executable. > >>> > >>> Mode #2 > >>> Support separate .a as jlink input. Jlink could pass the path > >>> information to the .a libraries and other linker options to ld to > >>> create the executable. > >>> > >>> For both mode #1 and #2, jlink would then use the linker output > >>> executable to create the final hermetic image. > >>> > >>> Mode #3 > >>> Support a fully linked executable as a jlink input. When a linked > >>> executable is given to jlink, it can process it directly with other > >>> JDK data/files to create the final image, without native linking step. > >>> > >>> Any other thoughts and considerations? > >>> > >>> Best, > >>> Jiangli > >>> > >>>>> 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. > >>>> An alternative with less memory overhead could be using application > >>>> modular JAR and separate .a as the input for jlink. > >>>> > >>>>> 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. > >>>> Part of the current effort includes resolving the discovered symbol > >>>> collision issues with static linking. Will respond to your other email > >>>> on the symbol issue separately later. > >>>> > >>>>> 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. > >>>> I think we would need both configure flag and special target for the > >>>> static builds. > >>>> > >>>>> 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. > >>>> For the potential objcopy work to resolve symbol issues, we can add > >>>> that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We > >>>> have an internal prototype (not included in > >>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done > >>>> by one of colleagues for localizing symbols in libfreetype using > >>>> objcopy. > >>>> > >>>>> 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". > >>>> If we want to also build a fully statically linked launcher, maybe > >>>> --with-static-java? Being able to configure either dynamic, static or > >>>> both as you suggested also seems to be a good idea. > >>>> > >>>>> 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. > >>>> Completely agree. It would be good to avoid recompiling the .o file > >>>> for static and dynamic builds. As proposed in > >>>> https://bugs.openjdk.org/browse/JDK-8303796: > >>>> > >>>> It's beneficial to be able to build both .so and .a from the same set > >>>> of .o files. That would involve some changes to handle the dynamic JDK > >>>> and static JDK difference at runtime, instead of relying on the > >>>> STATIC_BUILD macro. > >>>> > >>>>> 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. > >>>> Renaming or redefining the symbol at build time could cause confusions > >>>> with debugging. That's a concern raised in > >>>> https://github.com/openjdk/jdk/pull/17456 discussions. > >>>> > >>>> Additionally, redefining symbols using tools like objcopy may not > >>>> handle member names referenced in string literals. For example, in > >>>> https://github.com/openjdk/jdk/pull/17456 additional changes are > >>>> needed in assembling and SA to reflect the symbol change. > >>>> > >>>>> 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? > >>>> We have done some testing with jtreg SA related tests for the fully > >>>> statically linked `javastatic`. > >>>> > >>>> If we use objcopy to localize symbols in hotspot, it's not yet clear > >>>> what's the impact on SA. We could do some tests. The other question > >>>> that I raised is the supported gcc versions (for partial linking) > >>>> related to the solution. > >>>> > >>>> Best, > >>>> Jiangli > >>>> > >>>>> /Magnus > >>>>> From duke at openjdk.org Wed Apr 17 19:04:27 2024 From: duke at openjdk.org (duke) Date: Wed, 17 Apr 2024 19:04:27 GMT Subject: git: openjdk/leyden: premain: Fix warning Message-ID: <809453e9-0e87-4ca7-9804-3c26b49f2a79@openjdk.org> Changeset: 48d45275 Author: Igor Veresov Date: 2024-04-17 12:03:52 +0000 URL: https://git.openjdk.org/leyden/commit/48d45275e18b8795839d9bc5ec3f63b57141bf02 Fix warning ! src/hotspot/share/oops/trainingData.cpp From magnus.ihse.bursie at oracle.com Thu Apr 18 10:28:37 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 18 Apr 2024 12:28:37 +0200 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <5b35878b-6413-4e3f-b9e3-a9b761516c99@oracle.com> Message-ID: <624a831e-6f5d-47dc-a2c9-3040dabb8fd4@oracle.com> On 2024-04-17 14:06, Julian Waters wrote: > Hi Magnus, > > Yes, I'm talking about the MSYS2 objcopy, but to a lesser extent also > standalone Windows objcopy builds too. objcopy should be able to > handle .o files from cl.exe (I assume that's what everyone here is > after considering all the talk about .o files?), but to answer that > question properly, I'd need a bit more detail. What kind of usage of > objcopy do you have in mind? A general-ish command line example could > be helpful To make a static library behave somewhat like a dynamic library, and not expose all its internal symbols to the rest of the world, there are basically two operations that needs to be done: 1) Combine all .o files into a single .o file, to make it look like it was compiled by a single source code. That way, symbols that were created in one source file and referenced in another will now behave as if they are internal to the "compilation unit", i.e. like they were declared static. 2) Modify the symbol status so that symbols that are not exported are changed so they look like they were actually declared "static" in the source code. These operations are based on concepts that exists in the gcc and clang toolchain, about symbol visibility. I am not sure how well they translate to a Microsoft setting. But, if the dll_export marker corresponds to visible symbols, then I guess we should be able to achieve something similar. What needs to be done then is: 1) Combine multiple .obj (COFF object files) into one. 2) Change the visibility of symbols that are not marked as dll_export:ed to they appear like they were declared static. In the clang/gcc world, the first step is done by "partial linking" by ld. That is our first blocker -- link.exe cannot do that. So the first question is really, is there a Windows build of ld that can work on COFF files to achieve this? The second step is done by objcopy using the "--localize-hidden" argument. The second question is, could this work on a COFF object file? /Magnus > > best regards, > Julian > > On Wed, Apr 17, 2024 at 5:55?PM Magnus Ihse Bursie > wrote: >> On 2024-04-16 07:23, Julian Waters wrote: >> >>>> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. >>> objcopy is also available on Windows, if the question about >>> alternative tooling is still unanswered :) >> At this point, I think support for static build on Windows is to either >> require additional tooling on top of the Microsoft Visual Studio >> toolchain, or to drop it completely, so I am definitely interested in >> researching alternatives. >> >> Can objcopy (I assume this is from msys?) deal with COFF files generated >> by cl? >> >> Switching the entire toolchain is not relevant at this point (but if a >> non-Microsoft toolchain build for Windows is ever integrated, it might >> get static builds with no extra work as a bonus), but I could certainly >> accept the idea of having one or a few additional tools required to get >> the normal Microsoft toolchain to produce static builds. >> >> /Magnus >> >>> best regards, >>> Julian >>> >>> On Fri, Apr 12, 2024 at 7:52?PM Magnus Ihse Bursie >>> wrote: >>>> On 2024-04-02 21:16, Jiangli Zhou wrote: >>>> >>>> Hi Magnus, >>>> >>>> In today's zoom meeting with Alan, Ron, Liam and Chuck, we (briefly) discussed how to move forward contributing the static Java related changes (additional runtime fixes/enhancements on top of the existing static support in JDK) from https://github.com/openjdk/leyden/tree/hermetic-java-runtime to JDK mainline. >>>> >>>> Just a bit more details/context below, which may be useful for others reading this thread. >>>> >>>> The https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch currently contains following for supporting hermetic Java (without the launcher work for runtime support): >>>> >>>> 1. Build change for linking the Java launcher (as bin/javastatic) with JDK/hotspot static libraries (.a), mainly in https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk. The part for creating the complete sets of static libraries (including libjvm.a) has already been included in the mainline since last year. https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk is in a very raw state and is intended to demonstrate the capability of building a static Java launcher. >>>> >>>> Indeed. It is nowhere near being able to be integrated. >>>> >>>> >>>> 2. Additional runtime fixes/enhancements on top of the existing static support in JDK, e.g. support further lookup dynamic native library if the built-in native library cannot be found. >>>> >>>> 3. Some initial (prototype) work on supporting hermetic JDK resource files in the jimage (JDK modules image). >>>> >>>> To move forward, one of the earliest items needed is to add the capability of building the fully statically linked Java launcher in JDK mainline. The other static Java runtime changes can be followed up after the launcher linking part, so they can be built and tested as individual PRs created for the JDK mainline. Magnus, you have expressed interest in helping get the launcher linking part (refactor from https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk) into JDK mainline. What's your thought on prioritizing the launcher static linking part before other makefile clean ups for static libraries? >>>> >>>> Trust me, my absolute top priority now is working on getting the proper build support needed for Hermetic Java. I can't prioritize it any higher. >>>> >>>> I am not sure what you are asking for. We can't just merge StaticLink.gmk from your prototype. And even if we did, what good will it do you? >>>> >>>> The problem you are running into is that the build system has not been designed to properly support static linking. There are already 3-4 hacks in place to get something sort-of useful out, but they are prone to breaking. I assume that we agree that for Hermetic Java to become a success, we need to have a stable foundation for static builds. >>>> >>>> The core problem of all static linking hacks is that they are not integrated in the right place. They need to be a core part of what NativeCompilation delivers, not something done in a separate file. To put it in other words, StaticLink.gmk from your branch do not need cleanup -- it needs to go away, and the functionality moved to the proper place. >>>> >>>> My approach is that NativeCompilation should support doing either only dynamic linking (as today), or static linking (as today with STATIC_LIBS or STATIC_BUILD), or both. The assumption is that the latter will be default, or at least should be tested by default in GHA. For this to work, we need to compile the source code to .o files only once, and then link these .o files either into a dynamic or a static library (or both). >>>> >>>> This, in turn, require several changes: >>>> >>>> 1) The linking code needs to be cleaned up, and all technical debt needs to be resolved. This is what I have been doing since I started working on static builds for Hermetic Java. JDK-8329704 (which was integrated yesterday) was the first major milestone of this cleanup. Now, the path were to find a library created by the JDK (static or dynamic) is encapsulated in ResolveLibPath. This is currently a monster, but at least all knowledge is collected in a single location, instead of spread over the code base. Getting this simplified is the next step. >>>> >>>> 2) We need to stop passing the STATIC_BUILD define when compiling. This is partially addressed in your PR, where you have replaced #ifdef STATIC_BUILD with a dynamic lookup. But there is also the problem of JNI/JVMTI entry points. I have been pondering how we can compile the code in a way so we support both dynamic and static name resolution, and I think I have a solution. >>>> >>>> This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. >>>> >>>> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. >>>> >>>> A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. >>>> >>>> My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. >>>> >>>> /Magnus >>>> >>>> >>>> >>>> Thanks! >>>> Jiangli >>>> >>>> On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: >>>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: >>>>>> Hi Magnus, >>>>>> >>>>>> Thanks for looking into this from the build perspective. >>>>>> >>>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie >>>>>> wrote: >>>>>>> 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. >>>>>> Some additional hermetic Java related references that are also useful: >>>>>> >>>>>> - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that >>>>>> links to the issues for resolving static linking issues so far >>>>>> - https://github.com/openjdk/jdk21/pull/26 is the enhancement for >>>>>> building the complete set of static libraries in JDK/VM, particularly >>>>>> including libjvm.a >>>>>> >>>>>>> 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? >>>>>> I have a similar view as Alan responded in your other email thread. >>>>>> Things are still in the early stage for the general solution. >>>>>> >>>>>> In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime >>>>>> branch, when configuring JDK with --with-static-java=yes, the JDK >>>>>> binary contains the following extra artifacts: >>>>>> >>>>>> - static-libs/*.a: The complete set of JDK/VM static libraries >>>>>> - jdk/bin/javastatic: A demo Java launcher fully statically linked >>>>>> with the selected JDK .a libraries (e.g. it currently statically link >>>>>> with the headless) and libjvm.a. It's the standard Java launcher >>>>>> without additional work for hermetic Java. >>>>>> >>>>>> In our prototype for hermetic Java, we build the hermetic executable >>>>>> image (a single image) from the following input (see description on >>>>>> singlejar packaging tool in >>>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf): >>>>>> >>>>>> - A customized launcher (with additional work for hermetic) executable >>>>>> fully statically linked with JDK/VM static libraries (.a files), >>>>>> application natives and dependencies (e.g. in .a static libraries) >>>>>> - JDK lib/modules, JDK resource files >>>>>> - Application classes and resource files >>>>>> >>>>>> Including a JDK library .a into the corresponding .jmod would require >>>>>> extracting the .a for linking with the executable. In some systems >>>>>> that may cause memory overhead due to the extracted copy of the .a >>>>>> files. I think we should consider the memory overhead issue. >>>>>> >>>>>> One possibility (as Alan described in his response) is for jlink to >>>>>> invoke the ld on the build system. jlink could pass the needed JDK >>>>>> static libraries and libjvm.a (provided as part of the JDK binary) to >>>>>> ld based on the modules required for the application. >>>>>> >>>>> I gave a bit more thoughts on this one. For jlink to trigger ld, it >>>>> would need to know the complete linker options and inputs. Those >>>>> include options and inputs related to the application part as well. In >>>>> some usages, it might be easier to handle native linking separately >>>>> and pass the linker output, the executable to jlink directly. Maybe we >>>>> could consider supporting different modes for various usages >>>>> requirements, from static libraries and native linking point of view: >>>>> >>>>> Mode #1 >>>>> Support .jmod packaged natives static libraries, for both JDK/VM .a >>>>> and application natives and dependencies. If the inputs to jlink >>>>> include .jmods, jlink can extract the .a libraries and pass the >>>>> information to ld to link the executable. >>>>> >>>>> Mode #2 >>>>> Support separate .a as jlink input. Jlink could pass the path >>>>> information to the .a libraries and other linker options to ld to >>>>> create the executable. >>>>> >>>>> For both mode #1 and #2, jlink would then use the linker output >>>>> executable to create the final hermetic image. >>>>> >>>>> Mode #3 >>>>> Support a fully linked executable as a jlink input. When a linked >>>>> executable is given to jlink, it can process it directly with other >>>>> JDK data/files to create the final image, without native linking step. >>>>> >>>>> Any other thoughts and considerations? >>>>> >>>>> Best, >>>>> Jiangli >>>>> >>>>>>> 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. >>>>>> An alternative with less memory overhead could be using application >>>>>> modular JAR and separate .a as the input for jlink. >>>>>> >>>>>>> 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. >>>>>> Part of the current effort includes resolving the discovered symbol >>>>>> collision issues with static linking. Will respond to your other email >>>>>> on the symbol issue separately later. >>>>>> >>>>>>> 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. >>>>>> I think we would need both configure flag and special target for the >>>>>> static builds. >>>>>> >>>>>>> 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. >>>>>> For the potential objcopy work to resolve symbol issues, we can add >>>>>> that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We >>>>>> have an internal prototype (not included in >>>>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done >>>>>> by one of colleagues for localizing symbols in libfreetype using >>>>>> objcopy. >>>>>> >>>>>>> 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". >>>>>> If we want to also build a fully statically linked launcher, maybe >>>>>> --with-static-java? Being able to configure either dynamic, static or >>>>>> both as you suggested also seems to be a good idea. >>>>>> >>>>>>> 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. >>>>>> Completely agree. It would be good to avoid recompiling the .o file >>>>>> for static and dynamic builds. As proposed in >>>>>> https://bugs.openjdk.org/browse/JDK-8303796: >>>>>> >>>>>> It's beneficial to be able to build both .so and .a from the same set >>>>>> of .o files. That would involve some changes to handle the dynamic JDK >>>>>> and static JDK difference at runtime, instead of relying on the >>>>>> STATIC_BUILD macro. >>>>>> >>>>>>> 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. >>>>>> Renaming or redefining the symbol at build time could cause confusions >>>>>> with debugging. That's a concern raised in >>>>>> https://github.com/openjdk/jdk/pull/17456 discussions. >>>>>> >>>>>> Additionally, redefining symbols using tools like objcopy may not >>>>>> handle member names referenced in string literals. For example, in >>>>>> https://github.com/openjdk/jdk/pull/17456 additional changes are >>>>>> needed in assembling and SA to reflect the symbol change. >>>>>> >>>>>>> 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? >>>>>> We have done some testing with jtreg SA related tests for the fully >>>>>> statically linked `javastatic`. >>>>>> >>>>>> If we use objcopy to localize symbols in hotspot, it's not yet clear >>>>>> what's the impact on SA. We could do some tests. The other question >>>>>> that I raised is the supported gcc versions (for partial linking) >>>>>> related to the solution. >>>>>> >>>>>> Best, >>>>>> Jiangli >>>>>> >>>>>>> /Magnus >>>>>>> From tanksherman27 at gmail.com Thu Apr 18 12:27:18 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Thu, 18 Apr 2024 20:27:18 +0800 Subject: Questions about the Hermetic Java project In-Reply-To: <624a831e-6f5d-47dc-a2c9-3040dabb8fd4@oracle.com> References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <5b35878b-6413-4e3f-b9e3-a9b761516c99@oracle.com> <624a831e-6f5d-47dc-a2c9-3040dabb8fd4@oracle.com> Message-ID: I have good (and bad news) for you! The good news is that from memory, ld and gcc (but I assume you are only concerned about ld) can work entirely on cl compiled object files with no hitch whatsoever, and partial linking is fully functional with ld on Windows! Symbol hiding also works, but with a gotcha. Now, the bad news. --localize-hidden, to my knowledge, only works on ELF visibilities. This means that for the following file: exports.c __declspec(dllexport) void exportedMethod() () void unexportedMethod() {} When objcopy is run over exports.o with --localize-hidden, it will work on the cl compiled object file just fine, but it will not recognise unexportedMethod() as a hidden method, because dllexport and hidden visibility are entirely separate concepts to gcc. The resulting exports-objcopy.o file will still have unexportedMethod as public. However, not all is lost just yet. --localize-symbol= still works perfectly fine, and can be used as a workaround if we can find a way to check for non-dllexport methods in cl object files and then feed that through the command line. I should note that clang also suffers from the same issue, as --localize-hidden on clang's objcopy also leaves unexportedMethod as public. Happy to help! best regards, Julian On Thu, Apr 18, 2024 at 6:28?PM Magnus Ihse Bursie wrote: > > On 2024-04-17 14:06, Julian Waters wrote: > > > Hi Magnus, > > > > Yes, I'm talking about the MSYS2 objcopy, but to a lesser extent also > > standalone Windows objcopy builds too. objcopy should be able to > > handle .o files from cl.exe (I assume that's what everyone here is > > after considering all the talk about .o files?), but to answer that > > question properly, I'd need a bit more detail. What kind of usage of > > objcopy do you have in mind? A general-ish command line example could > > be helpful > > To make a static library behave somewhat like a dynamic library, and not > expose all its internal symbols to the rest of the world, there are > basically two operations that needs to be done: > > 1) Combine all .o files into a single .o file, to make it look like it > was compiled by a single source code. That way, symbols that were > created in one source file and referenced in another will now behave as > if they are internal to the "compilation unit", i.e. like they were > declared static. > > 2) Modify the symbol status so that symbols that are not exported are > changed so they look like they were actually declared "static" in the > source code. > > These operations are based on concepts that exists in the gcc and clang > toolchain, about symbol visibility. I am not sure how well they > translate to a Microsoft setting. But, if the dll_export marker > corresponds to visible symbols, then I guess we should be able to > achieve something similar. > > What needs to be done then is: > > 1) Combine multiple .obj (COFF object files) into one. > > 2) Change the visibility of symbols that are not marked as dll_export:ed > to they appear like they were declared static. > > In the clang/gcc world, the first step is done by "partial linking" by > ld. That is our first blocker -- link.exe cannot do that. So the first > question is really, is there a Windows build of ld that can work on COFF > files to achieve this? > > The second step is done by objcopy using the "--localize-hidden" > argument. The second question is, could this work on a COFF object file? > > /Magnus > > > > > > best regards, > > Julian > > > > On Wed, Apr 17, 2024 at 5:55?PM Magnus Ihse Bursie > > wrote: > >> On 2024-04-16 07:23, Julian Waters wrote: > >> > >>>> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. > >>> objcopy is also available on Windows, if the question about > >>> alternative tooling is still unanswered :) > >> At this point, I think support for static build on Windows is to either > >> require additional tooling on top of the Microsoft Visual Studio > >> toolchain, or to drop it completely, so I am definitely interested in > >> researching alternatives. > >> > >> Can objcopy (I assume this is from msys?) deal with COFF files generated > >> by cl? > >> > >> Switching the entire toolchain is not relevant at this point (but if a > >> non-Microsoft toolchain build for Windows is ever integrated, it might > >> get static builds with no extra work as a bonus), but I could certainly > >> accept the idea of having one or a few additional tools required to get > >> the normal Microsoft toolchain to produce static builds. > >> > >> /Magnus > >> > >>> best regards, > >>> Julian > >>> > >>> On Fri, Apr 12, 2024 at 7:52?PM Magnus Ihse Bursie > >>> wrote: > >>>> On 2024-04-02 21:16, Jiangli Zhou wrote: > >>>> > >>>> Hi Magnus, > >>>> > >>>> In today's zoom meeting with Alan, Ron, Liam and Chuck, we (briefly) discussed how to move forward contributing the static Java related changes (additional runtime fixes/enhancements on top of the existing static support in JDK) from https://github.com/openjdk/leyden/tree/hermetic-java-runtime to JDK mainline. > >>>> > >>>> Just a bit more details/context below, which may be useful for others reading this thread. > >>>> > >>>> The https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch currently contains following for supporting hermetic Java (without the launcher work for runtime support): > >>>> > >>>> 1. Build change for linking the Java launcher (as bin/javastatic) with JDK/hotspot static libraries (.a), mainly in https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk. The part for creating the complete sets of static libraries (including libjvm.a) has already been included in the mainline since last year. https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk is in a very raw state and is intended to demonstrate the capability of building a static Java launcher. > >>>> > >>>> Indeed. It is nowhere near being able to be integrated. > >>>> > >>>> > >>>> 2. Additional runtime fixes/enhancements on top of the existing static support in JDK, e.g. support further lookup dynamic native library if the built-in native library cannot be found. > >>>> > >>>> 3. Some initial (prototype) work on supporting hermetic JDK resource files in the jimage (JDK modules image). > >>>> > >>>> To move forward, one of the earliest items needed is to add the capability of building the fully statically linked Java launcher in JDK mainline. The other static Java runtime changes can be followed up after the launcher linking part, so they can be built and tested as individual PRs created for the JDK mainline. Magnus, you have expressed interest in helping get the launcher linking part (refactor from https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk) into JDK mainline. What's your thought on prioritizing the launcher static linking part before other makefile clean ups for static libraries? > >>>> > >>>> Trust me, my absolute top priority now is working on getting the proper build support needed for Hermetic Java. I can't prioritize it any higher. > >>>> > >>>> I am not sure what you are asking for. We can't just merge StaticLink.gmk from your prototype. And even if we did, what good will it do you? > >>>> > >>>> The problem you are running into is that the build system has not been designed to properly support static linking. There are already 3-4 hacks in place to get something sort-of useful out, but they are prone to breaking. I assume that we agree that for Hermetic Java to become a success, we need to have a stable foundation for static builds. > >>>> > >>>> The core problem of all static linking hacks is that they are not integrated in the right place. They need to be a core part of what NativeCompilation delivers, not something done in a separate file. To put it in other words, StaticLink.gmk from your branch do not need cleanup -- it needs to go away, and the functionality moved to the proper place. > >>>> > >>>> My approach is that NativeCompilation should support doing either only dynamic linking (as today), or static linking (as today with STATIC_LIBS or STATIC_BUILD), or both. The assumption is that the latter will be default, or at least should be tested by default in GHA. For this to work, we need to compile the source code to .o files only once, and then link these .o files either into a dynamic or a static library (or both). > >>>> > >>>> This, in turn, require several changes: > >>>> > >>>> 1) The linking code needs to be cleaned up, and all technical debt needs to be resolved. This is what I have been doing since I started working on static builds for Hermetic Java. JDK-8329704 (which was integrated yesterday) was the first major milestone of this cleanup. Now, the path were to find a library created by the JDK (static or dynamic) is encapsulated in ResolveLibPath. This is currently a monster, but at least all knowledge is collected in a single location, instead of spread over the code base. Getting this simplified is the next step. > >>>> > >>>> 2) We need to stop passing the STATIC_BUILD define when compiling. This is partially addressed in your PR, where you have replaced #ifdef STATIC_BUILD with a dynamic lookup. But there is also the problem of JNI/JVMTI entry points. I have been pondering how we can compile the code in a way so we support both dynamic and static name resolution, and I think I have a solution. > >>>> > >>>> This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. > >>>> > >>>> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. > >>>> > >>>> A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. > >>>> > >>>> My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. > >>>> > >>>> /Magnus > >>>> > >>>> > >>>> > >>>> Thanks! > >>>> Jiangli > >>>> > >>>> On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: > >>>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: > >>>>>> Hi Magnus, > >>>>>> > >>>>>> Thanks for looking into this from the build perspective. > >>>>>> > >>>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie > >>>>>> wrote: > >>>>>>> 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. > >>>>>> Some additional hermetic Java related references that are also useful: > >>>>>> > >>>>>> - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that > >>>>>> links to the issues for resolving static linking issues so far > >>>>>> - https://github.com/openjdk/jdk21/pull/26 is the enhancement for > >>>>>> building the complete set of static libraries in JDK/VM, particularly > >>>>>> including libjvm.a > >>>>>> > >>>>>>> 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? > >>>>>> I have a similar view as Alan responded in your other email thread. > >>>>>> Things are still in the early stage for the general solution. > >>>>>> > >>>>>> In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime > >>>>>> branch, when configuring JDK with --with-static-java=yes, the JDK > >>>>>> binary contains the following extra artifacts: > >>>>>> > >>>>>> - static-libs/*.a: The complete set of JDK/VM static libraries > >>>>>> - jdk/bin/javastatic: A demo Java launcher fully statically linked > >>>>>> with the selected JDK .a libraries (e.g. it currently statically link > >>>>>> with the headless) and libjvm.a. It's the standard Java launcher > >>>>>> without additional work for hermetic Java. > >>>>>> > >>>>>> In our prototype for hermetic Java, we build the hermetic executable > >>>>>> image (a single image) from the following input (see description on > >>>>>> singlejar packaging tool in > >>>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf): > >>>>>> > >>>>>> - A customized launcher (with additional work for hermetic) executable > >>>>>> fully statically linked with JDK/VM static libraries (.a files), > >>>>>> application natives and dependencies (e.g. in .a static libraries) > >>>>>> - JDK lib/modules, JDK resource files > >>>>>> - Application classes and resource files > >>>>>> > >>>>>> Including a JDK library .a into the corresponding .jmod would require > >>>>>> extracting the .a for linking with the executable. In some systems > >>>>>> that may cause memory overhead due to the extracted copy of the .a > >>>>>> files. I think we should consider the memory overhead issue. > >>>>>> > >>>>>> One possibility (as Alan described in his response) is for jlink to > >>>>>> invoke the ld on the build system. jlink could pass the needed JDK > >>>>>> static libraries and libjvm.a (provided as part of the JDK binary) to > >>>>>> ld based on the modules required for the application. > >>>>>> > >>>>> I gave a bit more thoughts on this one. For jlink to trigger ld, it > >>>>> would need to know the complete linker options and inputs. Those > >>>>> include options and inputs related to the application part as well. In > >>>>> some usages, it might be easier to handle native linking separately > >>>>> and pass the linker output, the executable to jlink directly. Maybe we > >>>>> could consider supporting different modes for various usages > >>>>> requirements, from static libraries and native linking point of view: > >>>>> > >>>>> Mode #1 > >>>>> Support .jmod packaged natives static libraries, for both JDK/VM .a > >>>>> and application natives and dependencies. If the inputs to jlink > >>>>> include .jmods, jlink can extract the .a libraries and pass the > >>>>> information to ld to link the executable. > >>>>> > >>>>> Mode #2 > >>>>> Support separate .a as jlink input. Jlink could pass the path > >>>>> information to the .a libraries and other linker options to ld to > >>>>> create the executable. > >>>>> > >>>>> For both mode #1 and #2, jlink would then use the linker output > >>>>> executable to create the final hermetic image. > >>>>> > >>>>> Mode #3 > >>>>> Support a fully linked executable as a jlink input. When a linked > >>>>> executable is given to jlink, it can process it directly with other > >>>>> JDK data/files to create the final image, without native linking step. > >>>>> > >>>>> Any other thoughts and considerations? > >>>>> > >>>>> Best, > >>>>> Jiangli > >>>>> > >>>>>>> 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. > >>>>>> An alternative with less memory overhead could be using application > >>>>>> modular JAR and separate .a as the input for jlink. > >>>>>> > >>>>>>> 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. > >>>>>> Part of the current effort includes resolving the discovered symbol > >>>>>> collision issues with static linking. Will respond to your other email > >>>>>> on the symbol issue separately later. > >>>>>> > >>>>>>> 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. > >>>>>> I think we would need both configure flag and special target for the > >>>>>> static builds. > >>>>>> > >>>>>>> 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. > >>>>>> For the potential objcopy work to resolve symbol issues, we can add > >>>>>> that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We > >>>>>> have an internal prototype (not included in > >>>>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done > >>>>>> by one of colleagues for localizing symbols in libfreetype using > >>>>>> objcopy. > >>>>>> > >>>>>>> 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". > >>>>>> If we want to also build a fully statically linked launcher, maybe > >>>>>> --with-static-java? Being able to configure either dynamic, static or > >>>>>> both as you suggested also seems to be a good idea. > >>>>>> > >>>>>>> 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. > >>>>>> Completely agree. It would be good to avoid recompiling the .o file > >>>>>> for static and dynamic builds. As proposed in > >>>>>> https://bugs.openjdk.org/browse/JDK-8303796: > >>>>>> > >>>>>> It's beneficial to be able to build both .so and .a from the same set > >>>>>> of .o files. That would involve some changes to handle the dynamic JDK > >>>>>> and static JDK difference at runtime, instead of relying on the > >>>>>> STATIC_BUILD macro. > >>>>>> > >>>>>>> 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. > >>>>>> Renaming or redefining the symbol at build time could cause confusions > >>>>>> with debugging. That's a concern raised in > >>>>>> https://github.com/openjdk/jdk/pull/17456 discussions. > >>>>>> > >>>>>> Additionally, redefining symbols using tools like objcopy may not > >>>>>> handle member names referenced in string literals. For example, in > >>>>>> https://github.com/openjdk/jdk/pull/17456 additional changes are > >>>>>> needed in assembling and SA to reflect the symbol change. > >>>>>> > >>>>>>> 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? > >>>>>> We have done some testing with jtreg SA related tests for the fully > >>>>>> statically linked `javastatic`. > >>>>>> > >>>>>> If we use objcopy to localize symbols in hotspot, it's not yet clear > >>>>>> what's the impact on SA. We could do some tests. The other question > >>>>>> that I raised is the supported gcc versions (for partial linking) > >>>>>> related to the solution. > >>>>>> > >>>>>> Best, > >>>>>> Jiangli > >>>>>> > >>>>>>> /Magnus > >>>>>>> From tanksherman27 at gmail.com Thu Apr 18 12:31:25 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Thu, 18 Apr 2024 20:31:25 +0800 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <5b35878b-6413-4e3f-b9e3-a9b761516c99@oracle.com> <624a831e-6f5d-47dc-a2c9-3040dabb8fd4@oracle.com> Message-ID: Oops, I meant __declspec(dllexport) void exportedMethod() {} with braces, not brackets On Thu, Apr 18, 2024 at 8:27?PM Julian Waters wrote: > > I have good (and bad news) for you! > > The good news is that from memory, ld and gcc (but I assume you are > only concerned about ld) can work entirely on cl compiled object files > with no hitch whatsoever, and partial linking is fully functional with > ld on Windows! Symbol hiding also works, but with a gotcha. > > Now, the bad news. --localize-hidden, to my knowledge, only works on > ELF visibilities. This means that for the following file: > > exports.c > __declspec(dllexport) void exportedMethod() () > void unexportedMethod() {} > > When objcopy is run over exports.o with --localize-hidden, it will > work on the cl compiled object file just fine, but it will not > recognise unexportedMethod() as a hidden method, because dllexport and > hidden visibility are entirely separate concepts to gcc. The resulting > exports-objcopy.o file will still have unexportedMethod as public. > However, not all is lost just yet. --localize-symbol= still > works perfectly fine, and can be used as a workaround if we can find a > way to check for non-dllexport methods in cl object files and then > feed that through the command line. I should note that clang also > suffers from the same issue, as --localize-hidden on clang's objcopy > also leaves unexportedMethod as public. > > Happy to help! > > best regards, > Julian > > On Thu, Apr 18, 2024 at 6:28?PM Magnus Ihse Bursie > wrote: > > > > On 2024-04-17 14:06, Julian Waters wrote: > > > > > Hi Magnus, > > > > > > Yes, I'm talking about the MSYS2 objcopy, but to a lesser extent also > > > standalone Windows objcopy builds too. objcopy should be able to > > > handle .o files from cl.exe (I assume that's what everyone here is > > > after considering all the talk about .o files?), but to answer that > > > question properly, I'd need a bit more detail. What kind of usage of > > > objcopy do you have in mind? A general-ish command line example could > > > be helpful > > > > To make a static library behave somewhat like a dynamic library, and not > > expose all its internal symbols to the rest of the world, there are > > basically two operations that needs to be done: > > > > 1) Combine all .o files into a single .o file, to make it look like it > > was compiled by a single source code. That way, symbols that were > > created in one source file and referenced in another will now behave as > > if they are internal to the "compilation unit", i.e. like they were > > declared static. > > > > 2) Modify the symbol status so that symbols that are not exported are > > changed so they look like they were actually declared "static" in the > > source code. > > > > These operations are based on concepts that exists in the gcc and clang > > toolchain, about symbol visibility. I am not sure how well they > > translate to a Microsoft setting. But, if the dll_export marker > > corresponds to visible symbols, then I guess we should be able to > > achieve something similar. > > > > What needs to be done then is: > > > > 1) Combine multiple .obj (COFF object files) into one. > > > > 2) Change the visibility of symbols that are not marked as dll_export:ed > > to they appear like they were declared static. > > > > In the clang/gcc world, the first step is done by "partial linking" by > > ld. That is our first blocker -- link.exe cannot do that. So the first > > question is really, is there a Windows build of ld that can work on COFF > > files to achieve this? > > > > The second step is done by objcopy using the "--localize-hidden" > > argument. The second question is, could this work on a COFF object file? > > > > /Magnus > > > > > > > > > > best regards, > > > Julian > > > > > > On Wed, Apr 17, 2024 at 5:55?PM Magnus Ihse Bursie > > > wrote: > > >> On 2024-04-16 07:23, Julian Waters wrote: > > >> > > >>>> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. > > >>> objcopy is also available on Windows, if the question about > > >>> alternative tooling is still unanswered :) > > >> At this point, I think support for static build on Windows is to either > > >> require additional tooling on top of the Microsoft Visual Studio > > >> toolchain, or to drop it completely, so I am definitely interested in > > >> researching alternatives. > > >> > > >> Can objcopy (I assume this is from msys?) deal with COFF files generated > > >> by cl? > > >> > > >> Switching the entire toolchain is not relevant at this point (but if a > > >> non-Microsoft toolchain build for Windows is ever integrated, it might > > >> get static builds with no extra work as a bonus), but I could certainly > > >> accept the idea of having one or a few additional tools required to get > > >> the normal Microsoft toolchain to produce static builds. > > >> > > >> /Magnus > > >> > > >>> best regards, > > >>> Julian > > >>> > > >>> On Fri, Apr 12, 2024 at 7:52?PM Magnus Ihse Bursie > > >>> wrote: > > >>>> On 2024-04-02 21:16, Jiangli Zhou wrote: > > >>>> > > >>>> Hi Magnus, > > >>>> > > >>>> In today's zoom meeting with Alan, Ron, Liam and Chuck, we (briefly) discussed how to move forward contributing the static Java related changes (additional runtime fixes/enhancements on top of the existing static support in JDK) from https://github.com/openjdk/leyden/tree/hermetic-java-runtime to JDK mainline. > > >>>> > > >>>> Just a bit more details/context below, which may be useful for others reading this thread. > > >>>> > > >>>> The https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch currently contains following for supporting hermetic Java (without the launcher work for runtime support): > > >>>> > > >>>> 1. Build change for linking the Java launcher (as bin/javastatic) with JDK/hotspot static libraries (.a), mainly in https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk. The part for creating the complete sets of static libraries (including libjvm.a) has already been included in the mainline since last year. https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk is in a very raw state and is intended to demonstrate the capability of building a static Java launcher. > > >>>> > > >>>> Indeed. It is nowhere near being able to be integrated. > > >>>> > > >>>> > > >>>> 2. Additional runtime fixes/enhancements on top of the existing static support in JDK, e.g. support further lookup dynamic native library if the built-in native library cannot be found. > > >>>> > > >>>> 3. Some initial (prototype) work on supporting hermetic JDK resource files in the jimage (JDK modules image). > > >>>> > > >>>> To move forward, one of the earliest items needed is to add the capability of building the fully statically linked Java launcher in JDK mainline. The other static Java runtime changes can be followed up after the launcher linking part, so they can be built and tested as individual PRs created for the JDK mainline. Magnus, you have expressed interest in helping get the launcher linking part (refactor from https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk) into JDK mainline. What's your thought on prioritizing the launcher static linking part before other makefile clean ups for static libraries? > > >>>> > > >>>> Trust me, my absolute top priority now is working on getting the proper build support needed for Hermetic Java. I can't prioritize it any higher. > > >>>> > > >>>> I am not sure what you are asking for. We can't just merge StaticLink.gmk from your prototype. And even if we did, what good will it do you? > > >>>> > > >>>> The problem you are running into is that the build system has not been designed to properly support static linking. There are already 3-4 hacks in place to get something sort-of useful out, but they are prone to breaking. I assume that we agree that for Hermetic Java to become a success, we need to have a stable foundation for static builds. > > >>>> > > >>>> The core problem of all static linking hacks is that they are not integrated in the right place. They need to be a core part of what NativeCompilation delivers, not something done in a separate file. To put it in other words, StaticLink.gmk from your branch do not need cleanup -- it needs to go away, and the functionality moved to the proper place. > > >>>> > > >>>> My approach is that NativeCompilation should support doing either only dynamic linking (as today), or static linking (as today with STATIC_LIBS or STATIC_BUILD), or both. The assumption is that the latter will be default, or at least should be tested by default in GHA. For this to work, we need to compile the source code to .o files only once, and then link these .o files either into a dynamic or a static library (or both). > > >>>> > > >>>> This, in turn, require several changes: > > >>>> > > >>>> 1) The linking code needs to be cleaned up, and all technical debt needs to be resolved. This is what I have been doing since I started working on static builds for Hermetic Java. JDK-8329704 (which was integrated yesterday) was the first major milestone of this cleanup. Now, the path were to find a library created by the JDK (static or dynamic) is encapsulated in ResolveLibPath. This is currently a monster, but at least all knowledge is collected in a single location, instead of spread over the code base. Getting this simplified is the next step. > > >>>> > > >>>> 2) We need to stop passing the STATIC_BUILD define when compiling. This is partially addressed in your PR, where you have replaced #ifdef STATIC_BUILD with a dynamic lookup. But there is also the problem of JNI/JVMTI entry points. I have been pondering how we can compile the code in a way so we support both dynamic and static name resolution, and I think I have a solution. > > >>>> > > >>>> This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. > > >>>> > > >>>> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. > > >>>> > > >>>> A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. > > >>>> > > >>>> My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. > > >>>> > > >>>> /Magnus > > >>>> > > >>>> > > >>>> > > >>>> Thanks! > > >>>> Jiangli > > >>>> > > >>>> On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: > > >>>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: > > >>>>>> Hi Magnus, > > >>>>>> > > >>>>>> Thanks for looking into this from the build perspective. > > >>>>>> > > >>>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie > > >>>>>> wrote: > > >>>>>>> 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. > > >>>>>> Some additional hermetic Java related references that are also useful: > > >>>>>> > > >>>>>> - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that > > >>>>>> links to the issues for resolving static linking issues so far > > >>>>>> - https://github.com/openjdk/jdk21/pull/26 is the enhancement for > > >>>>>> building the complete set of static libraries in JDK/VM, particularly > > >>>>>> including libjvm.a > > >>>>>> > > >>>>>>> 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? > > >>>>>> I have a similar view as Alan responded in your other email thread. > > >>>>>> Things are still in the early stage for the general solution. > > >>>>>> > > >>>>>> In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime > > >>>>>> branch, when configuring JDK with --with-static-java=yes, the JDK > > >>>>>> binary contains the following extra artifacts: > > >>>>>> > > >>>>>> - static-libs/*.a: The complete set of JDK/VM static libraries > > >>>>>> - jdk/bin/javastatic: A demo Java launcher fully statically linked > > >>>>>> with the selected JDK .a libraries (e.g. it currently statically link > > >>>>>> with the headless) and libjvm.a. It's the standard Java launcher > > >>>>>> without additional work for hermetic Java. > > >>>>>> > > >>>>>> In our prototype for hermetic Java, we build the hermetic executable > > >>>>>> image (a single image) from the following input (see description on > > >>>>>> singlejar packaging tool in > > >>>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf): > > >>>>>> > > >>>>>> - A customized launcher (with additional work for hermetic) executable > > >>>>>> fully statically linked with JDK/VM static libraries (.a files), > > >>>>>> application natives and dependencies (e.g. in .a static libraries) > > >>>>>> - JDK lib/modules, JDK resource files > > >>>>>> - Application classes and resource files > > >>>>>> > > >>>>>> Including a JDK library .a into the corresponding .jmod would require > > >>>>>> extracting the .a for linking with the executable. In some systems > > >>>>>> that may cause memory overhead due to the extracted copy of the .a > > >>>>>> files. I think we should consider the memory overhead issue. > > >>>>>> > > >>>>>> One possibility (as Alan described in his response) is for jlink to > > >>>>>> invoke the ld on the build system. jlink could pass the needed JDK > > >>>>>> static libraries and libjvm.a (provided as part of the JDK binary) to > > >>>>>> ld based on the modules required for the application. > > >>>>>> > > >>>>> I gave a bit more thoughts on this one. For jlink to trigger ld, it > > >>>>> would need to know the complete linker options and inputs. Those > > >>>>> include options and inputs related to the application part as well. In > > >>>>> some usages, it might be easier to handle native linking separately > > >>>>> and pass the linker output, the executable to jlink directly. Maybe we > > >>>>> could consider supporting different modes for various usages > > >>>>> requirements, from static libraries and native linking point of view: > > >>>>> > > >>>>> Mode #1 > > >>>>> Support .jmod packaged natives static libraries, for both JDK/VM .a > > >>>>> and application natives and dependencies. If the inputs to jlink > > >>>>> include .jmods, jlink can extract the .a libraries and pass the > > >>>>> information to ld to link the executable. > > >>>>> > > >>>>> Mode #2 > > >>>>> Support separate .a as jlink input. Jlink could pass the path > > >>>>> information to the .a libraries and other linker options to ld to > > >>>>> create the executable. > > >>>>> > > >>>>> For both mode #1 and #2, jlink would then use the linker output > > >>>>> executable to create the final hermetic image. > > >>>>> > > >>>>> Mode #3 > > >>>>> Support a fully linked executable as a jlink input. When a linked > > >>>>> executable is given to jlink, it can process it directly with other > > >>>>> JDK data/files to create the final image, without native linking step. > > >>>>> > > >>>>> Any other thoughts and considerations? > > >>>>> > > >>>>> Best, > > >>>>> Jiangli > > >>>>> > > >>>>>>> 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. > > >>>>>> An alternative with less memory overhead could be using application > > >>>>>> modular JAR and separate .a as the input for jlink. > > >>>>>> > > >>>>>>> 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. > > >>>>>> Part of the current effort includes resolving the discovered symbol > > >>>>>> collision issues with static linking. Will respond to your other email > > >>>>>> on the symbol issue separately later. > > >>>>>> > > >>>>>>> 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. > > >>>>>> I think we would need both configure flag and special target for the > > >>>>>> static builds. > > >>>>>> > > >>>>>>> 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. > > >>>>>> For the potential objcopy work to resolve symbol issues, we can add > > >>>>>> that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We > > >>>>>> have an internal prototype (not included in > > >>>>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done > > >>>>>> by one of colleagues for localizing symbols in libfreetype using > > >>>>>> objcopy. > > >>>>>> > > >>>>>>> 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". > > >>>>>> If we want to also build a fully statically linked launcher, maybe > > >>>>>> --with-static-java? Being able to configure either dynamic, static or > > >>>>>> both as you suggested also seems to be a good idea. > > >>>>>> > > >>>>>>> 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. > > >>>>>> Completely agree. It would be good to avoid recompiling the .o file > > >>>>>> for static and dynamic builds. As proposed in > > >>>>>> https://bugs.openjdk.org/browse/JDK-8303796: > > >>>>>> > > >>>>>> It's beneficial to be able to build both .so and .a from the same set > > >>>>>> of .o files. That would involve some changes to handle the dynamic JDK > > >>>>>> and static JDK difference at runtime, instead of relying on the > > >>>>>> STATIC_BUILD macro. > > >>>>>> > > >>>>>>> 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. > > >>>>>> Renaming or redefining the symbol at build time could cause confusions > > >>>>>> with debugging. That's a concern raised in > > >>>>>> https://github.com/openjdk/jdk/pull/17456 discussions. > > >>>>>> > > >>>>>> Additionally, redefining symbols using tools like objcopy may not > > >>>>>> handle member names referenced in string literals. For example, in > > >>>>>> https://github.com/openjdk/jdk/pull/17456 additional changes are > > >>>>>> needed in assembling and SA to reflect the symbol change. > > >>>>>> > > >>>>>>> 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? > > >>>>>> We have done some testing with jtreg SA related tests for the fully > > >>>>>> statically linked `javastatic`. > > >>>>>> > > >>>>>> If we use objcopy to localize symbols in hotspot, it's not yet clear > > >>>>>> what's the impact on SA. We could do some tests. The other question > > >>>>>> that I raised is the supported gcc versions (for partial linking) > > >>>>>> related to the solution. > > >>>>>> > > >>>>>> Best, > > >>>>>> Jiangli > > >>>>>> > > >>>>>>> /Magnus > > >>>>>>> From dean.long at oracle.com Thu Apr 18 22:35:16 2024 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 18 Apr 2024 15:35:16 -0700 Subject: Questions about the Hermetic Java project In-Reply-To: <624a831e-6f5d-47dc-a2c9-3040dabb8fd4@oracle.com> References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <5b35878b-6413-4e3f-b9e3-a9b761516c99@oracle.com> <624a831e-6f5d-47dc-a2c9-3040dabb8fd4@oracle.com> Message-ID: <5d9763e9-87a9-450e-b436-deb74d557ca8@oracle.com> There is also the LIB command, which creates the equivalent of a .a library, but with an explicit export list: https://learn.microsoft.com/en-us/cpp/build/reference/building-an-import-library-and-export-file?view=msvc-170 dl On 4/18/24 3:28 AM, Magnus Ihse Bursie wrote: > What needs to be done then is: > > 1) Combine multiple .obj (COFF object files) into one. > > 2) Change the visibility of symbols that are not marked as > dll_export:ed to they appear like they were declared static. > > In the clang/gcc world, the first step is done by "partial linking" by > ld. That is our first blocker -- link.exe cannot do that. So the first > question is really, is there a Windows build of ld that can work on > COFF files to achieve this? > > The second step is done by objcopy using the "--localize-hidden" > argument. The second question is, could this work on a COFF object file? From magnus.ihse.bursie at oracle.com Fri Apr 19 10:48:09 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 19 Apr 2024 12:48:09 +0200 Subject: Questions about the Hermetic Java project In-Reply-To: <5d9763e9-87a9-450e-b436-deb74d557ca8@oracle.com> References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <5b35878b-6413-4e3f-b9e3-a9b761516c99@oracle.com> <624a831e-6f5d-47dc-a2c9-3040dabb8fd4@oracle.com> <5d9763e9-87a9-450e-b436-deb74d557ca8@oracle.com> Message-ID: <1a085d1a-226f-4b44-a249-4184f409d41e@oracle.com> On 2024-04-19 00:35, dean.long at oracle.com wrote: > There is also the LIB command, which creates the equivalent of a .a > library, but with an explicit export list: > > https://learn.microsoft.com/en-us/cpp/build/reference/building-an-import-library-and-export-file?view=msvc-170 > This is where the Microsoft toolchain gets confusing. This will only create an *import* library. An import library does not have a corresponding concept in the clang/gcc toolchain. It is a static library, yes, but it is a shim library with the single trivial purpose to load and initialize the corresponding dll. So this does not help us in building a "proper" static library. Unfortunately, this distinction was not entirely clear to me or the other initial authors of the JDK build system, so things are confusing there as well with regard to this. (I plan to address this.) /Magnus > > dl > > On 4/18/24 3:28 AM, Magnus Ihse Bursie wrote: >> What needs to be done then is: >> >> 1) Combine multiple .obj (COFF object files) into one. >> >> 2) Change the visibility of symbols that are not marked as >> dll_export:ed to they appear like they were declared static. >> >> In the clang/gcc world, the first step is done by "partial linking" >> by ld. That is our first blocker -- link.exe cannot do that. So the >> first question is really, is there a Windows build of ld that can >> work on COFF files to achieve this? >> >> The second step is done by objcopy using the "--localize-hidden" >> argument. The second question is, could this work on a COFF object file? From dean.long at oracle.com Fri Apr 19 20:49:40 2024 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 19 Apr 2024 13:49:40 -0700 Subject: Questions about the Hermetic Java project In-Reply-To: <1a085d1a-226f-4b44-a249-4184f409d41e@oracle.com> References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <5b35878b-6413-4e3f-b9e3-a9b761516c99@oracle.com> <624a831e-6f5d-47dc-a2c9-3040dabb8fd4@oracle.com> <5d9763e9-87a9-450e-b436-deb74d557ca8@oracle.com> <1a085d1a-226f-4b44-a249-4184f409d41e@oracle.com> Message-ID: That probably was the wrong link to send.? According to this: https://learn.microsoft.com/en-us/cpp/build/reference/dot-lib-files-as-linker-input?view=msvc-170 LIB can be used to create a standard library containing object files, which sounds like a Unix .a library.? But without an intermediate linking step, using .lib files from different modules to link the final .exe would be problematic, unless there was a way to tell the linker to perform /intra/-LIB symbol resolution first, before /inter/-LIB resolution. dl On 4/19/24 3:48 AM, Magnus Ihse Bursie wrote: > On 2024-04-19 00:35, dean.long at oracle.com wrote: > >> There is also the LIB command, which creates the equivalent of a .a >> library, but with an explicit export list: >> >> https://learn.microsoft.com/en-us/cpp/build/reference/building-an-import-library-and-export-file?view=msvc-170 >> > > This is where the Microsoft toolchain gets confusing. This will only > create an *import* library. An import library does not have a > corresponding concept in the clang/gcc toolchain. It is a static > library, yes, but it is a shim library with the single trivial purpose > to load and initialize the corresponding dll. So this does not help us > in building a "proper" static library. > > Unfortunately, this distinction was not entirely clear to me or the > other initial authors of the JDK build system, so things are confusing > there as well with regard to this. (I plan to address this.) > > /Magnus > >> >> dl >> >> On 4/18/24 3:28 AM, Magnus Ihse Bursie wrote: >>> What needs to be done then is: >>> >>> 1) Combine multiple .obj (COFF object files) into one. >>> >>> 2) Change the visibility of symbols that are not marked as >>> dll_export:ed to they appear like they were declared static. >>> >>> In the clang/gcc world, the first step is done by "partial linking" >>> by ld. That is our first blocker -- link.exe cannot do that. So the >>> first question is really, is there a Windows build of ld that can >>> work on COFF files to achieve this? >>> >>> The second step is done by objcopy using the "--localize-hidden" >>> argument. The second question is, could this work on a COFF object >>> file? -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sat Apr 20 02:16:08 2024 From: duke at openjdk.org (duke) Date: Sat, 20 Apr 2024 02:16:08 GMT Subject: git: openjdk/leyden: premain: 8321944: fix PcDesc cache initialization Message-ID: <150a003b-ca8e-4093-a6b5-9024da012519@openjdk.org> Changeset: 811bad88 Author: Vladimir Kozlov Date: 2024-04-19 19:15:45 +0000 URL: https://git.openjdk.org/leyden/commit/811bad8841ac532c23fda441492ad9e757f9ee96 8321944: fix PcDesc cache initialization ! src/hotspot/share/code/nmethod.cpp From duke at openjdk.org Tue Apr 23 04:46:18 2024 From: duke at openjdk.org (duke) Date: Tue, 23 Apr 2024 04:46:18 GMT Subject: git: openjdk/leyden: premain: 2 new changesets Message-ID: <16a63d0c-3d96-43df-afe3-79e21118289f@openjdk.org> Changeset: 64987121 Author: iklam Date: 2024-04-22 20:38:56 +0000 URL: https://git.openjdk.org/leyden/commit/649871210ab72a7bfe38aa9995738d219f8dbef6 Original code unpacked from https://guides.micronaut.io/latest/creating-your-first-micronaut-app-maven-java.zip , downloaded on 2024/04/22 + test/hotspot/jtreg/premain/micronaut-first-app/README.md + test/hotspot/jtreg/premain/micronaut-first-app/download/.mvn/wrapper/maven-wrapper.jar + test/hotspot/jtreg/premain/micronaut-first-app/download/.mvn/wrapper/maven-wrapper.properties + test/hotspot/jtreg/premain/micronaut-first-app/download/LICENSEHEADER + test/hotspot/jtreg/premain/micronaut-first-app/download/README.md + test/hotspot/jtreg/premain/micronaut-first-app/download/aot-jar.properties + test/hotspot/jtreg/premain/micronaut-first-app/download/aot-native-image.properties + test/hotspot/jtreg/premain/micronaut-first-app/download/micronaut-cli.yml + test/hotspot/jtreg/premain/micronaut-first-app/download/mvnw + test/hotspot/jtreg/premain/micronaut-first-app/download/mvnw.bat + test/hotspot/jtreg/premain/micronaut-first-app/download/pom.xml + test/hotspot/jtreg/premain/micronaut-first-app/download/src/main/java/example/micronaut/Application.java + test/hotspot/jtreg/premain/micronaut-first-app/download/src/main/java/example/micronaut/HelloController.java + test/hotspot/jtreg/premain/micronaut-first-app/download/src/main/resources/application.properties + test/hotspot/jtreg/premain/micronaut-first-app/download/src/main/resources/logback.xml + test/hotspot/jtreg/premain/micronaut-first-app/download/src/test/java/example/micronaut/DefaultTest.java + test/hotspot/jtreg/premain/micronaut-first-app/download/src/test/java/example/micronaut/HelloControllerTest.java Changeset: 9fa97221 Author: iklam Date: 2024-04-22 21:42:36 +0000 URL: https://git.openjdk.org/leyden/commit/9fa972214934d30f67db5fd4d1b8007636ac1428 Added "Micronaut First App" as a test case + test/hotspot/jtreg/premain/micronaut-first-app/Makefile ! test/hotspot/jtreg/premain/micronaut-first-app/download/src/main/java/example/micronaut/Application.java ! test/hotspot/jtreg/runtime/cds/appcds/applications/HelidonQuickStartSE.java + test/hotspot/jtreg/runtime/cds/appcds/applications/MicronautFirstApp.java ! test/hotspot/jtreg/runtime/cds/appcds/applications/QuarkusGettingStarted.java From magnus.ihse.bursie at oracle.com Tue Apr 23 10:41:53 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 23 Apr 2024 12:41:53 +0200 Subject: Hermetic Java project meeting In-Reply-To: References: Message-ID: I will not be able to participate in the meeting today. Let me report a bit on my work this week. I have made a proof of concept branch which can properly compile static java on macos with clang and linux with gcc. (With "properly" I mean hiding non-exported symbols). I still have problems replicating the build with clang on linux. I suspect my linux workstation has a broken installation of clang. That machine has grown more erratic over time, and I need to reinstall it, but I'm procrastinating spending the time doing that... So for now I'm just skipping the clang on linux part. I have also made great progress on windows. Julian's hint about objcopy working fine on COFF, and being present in cygwin, got me to realize that this was in effect a possible way forward. My PoC currently manages to extract a list of exported symbols from the static libs using dumpbin. This is necessary since --localize-hidden does not work on COFF (the concept of "hidden" symbols is an ELF-only concept), and instead we need to use the --keep-global-symbols option, which (despite the name) converts all symbols in the given list to global and all other to local. I am currently working actively with getting the next steps done in this PoC. I have initiated talks with SAP, and they are interested in helping out getting static linking working on AIX (given that it is possible to do with not too much effort.) I have also tried to extract all the changes (and only the changes) related to static build from the hermetic-java-runtime branch (ignoring the JavaHome/resource loading changes), to see if I could get something like StaticLink.gmk in mainline. I thought I was doing quite fine, but after a while I realized my testing was botched since the launcher had actually loaded the libraries dynamically instead, even though they were statically linked. :-( I am currently trying to bisect my way thought my repo to understand where things went wrong. This problem was exaggerated by the fact that we cannot build *only* static libs, so the dynamic ones where there alongside to be (improperly) picked up. I might want to spend some time on fixing this first. That will help both with speeding up the build/test cycle for static builds, and help avoid that kind of issue repeating. That will require some more refactoring in the core build/link code though. Experimenting with the static launcher on linux/gcc and macos made me realize that we will need to know the set of external libraries needed by each individual JDK library. When building a dynamic library, this knowledge (e.g. -liconv -framework Application) is encoded into the lib*.so file by the linker. But not so for a static library. Instead, we need to store this information for each JDK library, and then in the end, when we want to pick up all static libraries and link them together to form the "javastatic" executable, we need to pass this set of external libraries to the linker. This was done haphazardly in StaticLink.gmk in the hermetic-java-runtime branch, where an arbitrary subset of external libraries were hard-coded. Before integration in mainline can be possible, this information needs to be collected correctly and automatically for all included JDK libraries. Fortunately, it is not likely to be too hard. I basically just need to store the information from the LIBS provided to the NativeCompilation, and pick that up for all static libraries we include in the static launcher. (A complication is that we need to de-duplicate the list, and that some libraries are specified using two words, like "-framework Application" on macos, so it will take some care getting it right.) I have also been thinking about possible ways that we can share compiled obj files between static and dynamic libraries, even if we cannot do it fully. Most files do not need the STATIC_BUILD define and will thus be identical for both static and dynamic builds. It might be possible to just hard-code the exact files that needs to be different. It's ugly, and I still would like to make sure we press forward with the spec changes to JNI/JVMTI, but it would work as a stop-gap measure. /Magnus From duke at openjdk.org Tue Apr 23 23:30:57 2024 From: duke at openjdk.org (duke) Date: Tue, 23 Apr 2024 23:30:57 GMT Subject: git: openjdk/leyden: premain: Added "make bench" in all four framework demos; added relative performance numbers to premain/README.md Message-ID: <8ccfee31-9f88-4976-a141-db742d96b70d@openjdk.org> Changeset: 04a95521 Author: iklam Date: 2024-04-23 16:29:39 +0000 URL: https://git.openjdk.org/leyden/commit/04a95521fc88327e25cbe88cf62fa54ed8caa3b2 Added "make bench" in all four framework demos; added relative performance numbers to premain/README.md ! test/hotspot/jtreg/premain/README.md ! test/hotspot/jtreg/premain/lib/DemoSupport.gmk + test/hotspot/jtreg/premain/lib/GithubMDChart.java ! test/hotspot/jtreg/premain/spring-petclinic/Makefile From duke at openjdk.org Tue Apr 23 23:35:38 2024 From: duke at openjdk.org (duke) Date: Tue, 23 Apr 2024 23:35:38 GMT Subject: git: openjdk/leyden: premain: Fixed graphs in MD file Message-ID: Changeset: c40b2993 Author: iklam Date: 2024-04-23 16:33:52 +0000 URL: https://git.openjdk.org/leyden/commit/c40b29931675514c9cd46d901d7d18d8e9544b0a Fixed graphs in MD file ! test/hotspot/jtreg/premain/README.md From duke at openjdk.org Tue Apr 23 23:47:37 2024 From: duke at openjdk.org (duke) Date: Tue, 23 Apr 2024 23:47:37 GMT Subject: git: openjdk/leyden: premain: minor benchmark tweaks Message-ID: Changeset: 74c0bfad Author: iklam Date: 2024-04-23 16:45:49 +0000 URL: https://git.openjdk.org/leyden/commit/74c0bfad65145a068ca6d9f51b38ae38a1fbc206 minor benchmark tweaks ! test/hotspot/jtreg/premain/README.md ! test/hotspot/jtreg/premain/lib/GithubMDChart.java From jianglizhou at google.com Wed Apr 24 17:57:17 2024 From: jianglizhou at google.com (Jiangli Zhou) Date: Wed, 24 Apr 2024 10:57:17 -0700 Subject: Hermetic Java project meeting In-Reply-To: References: Message-ID: Magnus, thanks for the update! Looks like you've made some good progress. Please see my comments below. On Tue, Apr 23, 2024 at 3:42?AM Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > I will not be able to participate in the meeting today. > > Let me report a bit on my work this week. > > I have made a proof of concept branch which can properly compile static > java on macos with clang and linux with gcc. (With "properly" I mean > hiding non-exported symbols). I still have problems replicating the > build with clang on linux. I suspect my linux workstation has a broken > installation of clang. That machine has grown more erratic over time, > and I need to reinstall it, but I'm procrastinating spending the time > doing that... So for now I'm just skipping the clang on linux part. > Just to be more clear, that's with using `objcopy` to localize non-exported symbols for all JDK static libraries and libjvm.a, not just libjvm.a right? Can you please include the compiler or linker errors on linux/clang? > > I have also made great progress on windows. Julian's hint about objcopy > working fine on COFF, and being present in cygwin, got me to realize > that this was in effect a possible way forward. My PoC currently manages > to extract a list of exported symbols from the static libs using > dumpbin. This is necessary since --localize-hidden does not work on COFF > (the concept of "hidden" symbols is an ELF-only concept), and instead we > need to use the --keep-global-symbols option, which (despite the name) > converts all symbols in the given list to global and all other to local. > I am currently working actively with getting the next steps done in this > PoC. > > I have initiated talks with SAP, and they are interested in helping out > getting static linking working on AIX (given that it is possible to do > with not too much effort.) > > I have also tried to extract all the changes (and only the changes) > related to static build from the hermetic-java-runtime branch (ignoring > the JavaHome/resource loading changes), to see if I could get something > like StaticLink.gmk in mainline. I thought I was doing quite fine, but > after a while I realized my testing was botched since the launcher had > actually loaded the libraries dynamically instead, even though they were > statically linked. :-( I am currently trying to bisect my way thought my > repo to understand where things went wrong. > Did you run with `bin/javastatic`? The system automatically detects if the binary contains statically linked native libraries and avoids loading the dynamic libraries. Can you please share which test(s) ran into the library loading issue? I'll see if I can reproduce the problem that you are running into. For your work to get StaticLink.gmk into the mainline, I suggest taking all changes in the hermetic-java-runtime branch for testing to simplify things on your side. Then you can just extract the makefile part to integrate with the mainline. As we've discussed in the zoom meeting, I'll work on getting the runtime changes for static support into the mainline incrementally. > This problem was exaggerated by the fact that we cannot build *only* > static libs, so the dynamic ones where there alongside to be > (improperly) picked up. I might want to spend some time on fixing this > first. That will help both with speeding up the build/test cycle for > static builds, and help avoid that kind of issue repeating. That will > require some more refactoring in the core build/link code though. > > Experimenting with the static launcher on linux/gcc and macos made me > realize that we will need to know the set of external libraries needed > by each individual JDK library. When building a dynamic library, this > knowledge (e.g. -liconv -framework Application) is encoded into the > lib*.so file by the linker. But not so for a static library. Instead, we > need to store this information for each JDK library, and then in the > end, when we want to pick up all static libraries and link them together > to form the "javastatic" executable, we need to pass this set of > external libraries to the linker. > > This was done haphazardly in StaticLink.gmk in the hermetic-java-runtime > branch, where an arbitrary subset of external libraries were hard-coded. > Before integration in mainline can be possible, this information needs > to be collected correctly and automatically for all included JDK > libraries. Fortunately, it is not likely to be too hard. I basically > just need to store the information from the LIBS provided to the > NativeCompilation, and pick that up for all static libraries we include > in the static launcher. (A complication is that we need to de-duplicate > the list, and that some libraries are specified using two words, like > "-framework Application" on macos, so it will take some care getting it > right.) > Right, currently the hermetic-java-runtime branch specifies a list of hard-coded dependency libraries for linking. One of the goals of the hermetic prototype was avoiding/reducing refactoring/restructuring the existing code whenever possible. The reason is to reduce merge overhead when integrating with new changes from the mainline. We can do the proper refactoring and cleanups when getting the changes into the mainline. > > I have also been thinking about possible ways that we can share compiled > obj files between static and dynamic libraries, even if we cannot do it > fully. Most files do not need the STATIC_BUILD define and will thus be > identical for both static and dynamic builds. It might be possible to > just hard-code the exact files that needs to be different. It's ugly, > and I still would like to make sure we press forward with the spec > changes to JNI/JVMTI, but it would work as a stop-gap measure. > We have only briefly touched on the spec change topic (for the naming of native libraries) during the zoom meetings. I also agree that we should get that part started now. It's unclear to me if there's any existing blocker for that. Best, Jiangli > > /Magnus > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Apr 25 00:54:23 2024 From: duke at openjdk.org (duke) Date: Thu, 25 Apr 2024 00:54:23 GMT Subject: git: openjdk/leyden: premain: 8331086: TrainingData allocation from Metaspace may fail Message-ID: Changeset: 8571089b Author: iklam Date: 2024-04-24 16:47:05 +0000 URL: https://git.openjdk.org/leyden/commit/8571089bc9b196c6d04de0062d9eca7ec5a3398d 8331086: TrainingData allocation from Metaspace may fail ! src/hotspot/share/memory/allocation.cpp ! src/hotspot/share/memory/allocation.hpp ! src/hotspot/share/memory/metadataFactory.hpp ! src/hotspot/share/oops/array.hpp ! src/hotspot/share/oops/array.inline.hpp ! src/hotspot/share/oops/trainingData.cpp From magnus.ihse.bursie at oracle.com Thu Apr 25 16:28:16 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 25 Apr 2024 18:28:16 +0200 Subject: Hermetic Java project meeting In-Reply-To: References: Message-ID: <65fdda77-1291-437e-b000-ca0307cf8084@oracle.com> > Just to be more clear, that's with using `objcopy` to localize > non-exported symbols for all JDK static libraries and libjvm.a, not > just libjvm.a right? Yes. > > Can you please include the compiler or linker errors on linux/clang? It is a bit tricky. The problem arises at the partial linking step. The problem seem to arise out of how clang converts a request to link into an actual call to ld. I enabled debug code (printing the command line, and running clang with `-v` to get it to print the actual command line used to run ld) and ran it on GHA, where it worked fine. This is how it looks there: WILL_RUN: /usr/bin/clang -v -m64 -r -o /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/librmi_relocatable.o /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/GC.o Ubuntu clang version 14.0.0-1ubuntu1.1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/10 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/11 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/12 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13 Candidate multilib: .;@m64 Selected multilib: .;@m64 "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/librmi_relocatable.o -L/usr/bin/../lib/gcc/x86_64-linux-gnu/13 -L/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/usr/lib/llvm-14/bin/../lib -L/lib -L/usr/lib -r /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/GC.o In contrast, on my machine it looks like this: WILL_RUN: /usr/local/clang+llvm-13.0.1-x86_64-linux-gnu-ubuntu-18.04/bin/clang -v -m64 -r -o /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/librmi_relocatable.o /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/GC.o clang version 13.0.1 Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/clang+llvm-13.0.1-x86_64-linux-gnu-ubuntu-18.04/bin Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 "/usr/bin/ld" --hash-style=both --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/librmi_relocatable.o /lib/x86_64-linux-gnu/crt1.o /lib/x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/9/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/9 -L/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/usr/local/clang+llvm-13.0.1-x86_64-linux-gnu-ubuntu-18.04/bin/../lib -L/lib -L/usr/lib -r /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/GC.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/9/crtend.o /lib/x86_64-linux-gnu/crtn.o /usr/bin/ld: cannot find -lgcc_s /usr/bin/ld: cannot find -lgcc_s clang-13: error: linker command failed with exit code 1 (use -v to see invocation) I don't understand what makes clang think it should include "-lgcc --as-needed -lgcc_s" and the crt*.o files when doing a partial link. In fact, the entire process on how clang (and gcc) builds up the linker command line is bordering on black magic to me. I think it can be affected by variables set at compile time (at least this was the case for gcc, last I checked), or maybe it picks up some kind of script from the environment. That's why I believe my machine could just be messed up. I could get a bit further by passing "-nodefaultlibs" (or whatever it was), but then the generated .o file were messed up wrt to library symbols and it failed dramatically when trying to do the final link of the static java launcher. > > I have also tried to extract all the changes (and only the changes) > related to static build from the hermetic-java-runtime branch > (ignoring > the JavaHome/resource loading changes), to see if I could get > something > like StaticLink.gmk in mainline. I thought I was doing quite fine, > but > after a while I realized my testing was botched since the launcher > had > actually loaded the libraries dynamically instead, even though > they were > statically linked. :-( I am currently trying to bisect my way > thought my > repo to understand where things went wrong. > > > Did you run with `bin/javastatic`? The system automatically detects if > the binary contains statically linked native libraries and avoids > loading the dynamic libraries. Can you please share which test(s) ran > into the library loading issue? I'll see if I can reproduce the > problem that you are?running into. It was in fact not a problem. I was fooled by an error message. To be sure I was not loading any dynamically linked libraries, I removed the jdk/lib directory. Now the launcher failed, saying something like: "Error: Cannot locate dynamic library libjava.dylib". which was a bit of a jump scare. However, it turned out that it actually tried to load lib/jvm.cfg, and failed in loading this (since I had removed the entire lib directory), and this failure caused the above error message to be printed. When I restored lib/jvm.cfg (but not any dynamic libraries), the launcher worked. There are several bugs lurking here. For once, the error message is incorrect and should be corrected. Secondly, a statically linked launcher has just a single JVM included and should not have to look for the lib/jvm.cfg file at all. After looking around a bit in the launcher/jli code, my conclusion is that this code will need some additional care and loving attention to make it properly adjusted to function as a static launcher. We can't have a static launcher that tries to load a jvm.cfg file it does not need, and when it fails, complains that it is missing a dynamic library that it should not load. I'll try to get this fixed as part of my efforts to get the static launcher into mainline. > This was done haphazardly in StaticLink.gmk in the > hermetic-java-runtime > branch, where an arbitrary subset of external libraries were > hard-coded. > Before integration in mainline can be possible, this information > needs > to be collected correctly and automatically for all included JDK > libraries. Fortunately, it is not likely to be too hard. I basically > just need to store the information from the LIBS provided to the > NativeCompilation, and pick that up for all static libraries we > include > in the static launcher. (A complication is that we need to > de-duplicate > the list, and that some libraries are specified using two words, like > "-framework Application" on macos, so it will take some care > getting it > right.) > > > Right, currently the hermetic-java-runtime branch specifies a list of > hard-coded dependency libraries for linking. One of the goals of the > hermetic prototype was?avoiding/reducing refactoring/restructuring the > existing code whenever possible. The reason is to reduce merge > overhead when integrating with new changes from the mainline. We can > do the proper refactoring and cleanups when getting the changes into > the mainline. That is basically what I am doing right now. I am looking at your prototype and trying to reimplement this functionality properly so that it can be merged into mainline. The first step on that way was to actually get your prototype running. Now I have managed to get a version of your prototype that only includes the minimal set of changes needed to support the static launcher, and that works on mac and linux/gcc. Since your prototype is based on 586396cbb55a31 from March, I am trying to merge the patch with the latest master. This worked fine for macOS, but I hit some unexpected snag on Linux which I'm currently investigating. > We have only briefly touched on the spec change topic (for the naming > of native libraries) during the zoom meetings. I also agree that we > should get that part started now. It's unclear to me if there's any > existing blocker for that. > I don't think there is. It's just that someone needs to step up and do it. /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Apr 25 16:54:14 2024 From: duke at openjdk.org (duke) Date: Thu, 25 Apr 2024 16:54:14 GMT Subject: git: openjdk/leyden: premain: 2 new changesets Message-ID: <071a3c96-8247-4307-b1a6-caec794f75c6@openjdk.org> Changeset: 192edefb Author: iklam Date: 2024-04-25 09:51:05 +0000 URL: https://git.openjdk.org/leyden/commit/192edefb8c07b0682e84886bf035ab930983d8f4 set CachedCodeMaxSize to 512M when StoreCachedCode is enabled ! src/hotspot/share/runtime/arguments.cpp Changeset: aa66815f Author: iklam Date: 2024-04-25 09:52:22 +0000 URL: https://git.openjdk.org/leyden/commit/aa66815f6993127c4a441052dc35dda95ab3aad4 Improved remove_unshareable_info for TrainingData (to avoid race condition where compiler thread might be adding more TD when we are collecting them ourside of the CDS safepoint) ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveBuilder.hpp ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/oops/methodData.hpp ! src/hotspot/share/oops/trainingData.cpp ! src/hotspot/share/oops/trainingData.hpp From duke at openjdk.org Thu Apr 25 21:58:19 2024 From: duke at openjdk.org (duke) Date: Thu, 25 Apr 2024 21:58:19 GMT Subject: git: openjdk/leyden: premain: Added instructions for running demos Message-ID: <599efa72-1dad-465d-81ab-093f94185733@openjdk.org> Changeset: 039c0219 Author: iklam Date: 2024-04-25 14:56:02 +0000 URL: https://git.openjdk.org/leyden/commit/039c02197c2695b61e73c1418b7e56dace9d3ae3 Added instructions for running demos ! test/hotspot/jtreg/premain/README.md ! test/hotspot/jtreg/premain/lib/DemoSupport.gmk ! test/hotspot/jtreg/premain/spring-petclinic/Makefile From jianglizhou at google.com Fri Apr 26 01:15:26 2024 From: jianglizhou at google.com (Jiangli Zhou) Date: Thu, 25 Apr 2024 18:15:26 -0700 Subject: Hermetic Java project meeting In-Reply-To: <65fdda77-1291-437e-b000-ca0307cf8084@oracle.com> References: <65fdda77-1291-437e-b000-ca0307cf8084@oracle.com> Message-ID: On Thu, Apr 25, 2024 at 9:28?AM Magnus Ihse Bursie wrote: > > > Just to be more clear, that's with using `objcopy` to localize non-exported symbols for all JDK static libraries and libjvm.a, not just libjvm.a right? > > Yes. > > > Can you please include the compiler or linker errors on linux/clang? > > It is a bit tricky. The problem arises at the partial linking step. The problem seem to arise out of how clang converts a request to link into an actual call to ld. I enabled debug code (printing the command line, and running clang with `-v` to get it to print the actual command line used to run ld) and ran it on GHA, where it worked fine. This is how it looks there: > > WILL_RUN: /usr/bin/clang -v -m64 -r -o /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/librmi_relocatable.o /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/GC.o > Ubuntu clang version 14.0.0-1ubuntu1.1 > Target: x86_64-pc-linux-gnu > Thread model: posix > InstalledDir: /usr/bin > Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/10 > Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/11 > Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/12 > Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13 > Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9 > Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13 > Candidate multilib: .;@m64 > Selected multilib: .;@m64 > "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/librmi_relocatable.o -L/usr/bin/../lib/gcc/x86_64-linux-gnu/13 -L/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/usr/lib/llvm-14/bin/../lib -L/lib -L/usr/lib -r /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/GC.o > > In contrast, on my machine it looks like this: > > WILL_RUN: /usr/local/clang+llvm-13.0.1-x86_64-linux-gnu-ubuntu-18.04/bin/clang -v -m64 -r -o /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/librmi_relocatable.o /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/GC.o > clang version 13.0.1 > Target: x86_64-unknown-linux-gnu > Thread model: posix > InstalledDir: /usr/local/clang+llvm-13.0.1-x86_64-linux-gnu-ubuntu-18.04/bin > Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9 > Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9 > Candidate multilib: .;@m64 > Candidate multilib: 32;@m32 > Candidate multilib: x32;@mx32 > Selected multilib: .;@m64 > "/usr/bin/ld" --hash-style=both --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/librmi_relocatable.o /lib/x86_64-linux-gnu/crt1.o /lib/x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/9/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/9 -L/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/usr/local/clang+llvm-13.0.1-x86_64-linux-gnu-ubuntu-18.04/bin/../lib -L/lib -L/usr/lib -r /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/GC.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/9/crtend.o /lib/x86_64-linux-gnu/crtn.o > /usr/bin/ld: cannot find -lgcc_s > /usr/bin/ld: cannot find -lgcc_s > clang-13: error: linker command failed with exit code 1 (use -v to see invocation) > > I don't understand what makes clang think it should include "-lgcc --as-needed -lgcc_s" and the crt*.o files when doing a partial link. In fact, the entire process on how clang (and gcc) builds up the linker command line is bordering on black magic to me. I think it can be affected by variables set at compile time (at least this was the case for gcc, last I checked), or maybe it picks up some kind of script from the environment. That's why I believe my machine could just be messed up. > > I could get a bit further by passing "-nodefaultlibs" (or whatever it was), but then the generated .o file were messed up wrt to library symbols and it failed dramatically when trying to do the final link of the static java launcher. > > Looks like you are using /usr/bin/ld and not lld. I haven't run into this type of issue. Have you tried -fuse-ld=lld? >> >> >> I have also tried to extract all the changes (and only the changes) >> related to static build from the hermetic-java-runtime branch (ignoring >> the JavaHome/resource loading changes), to see if I could get something >> like StaticLink.gmk in mainline. I thought I was doing quite fine, but >> after a while I realized my testing was botched since the launcher had >> actually loaded the libraries dynamically instead, even though they were >> statically linked. :-( I am currently trying to bisect my way thought my >> repo to understand where things went wrong. > > > Did you run with `bin/javastatic`? The system automatically detects if the binary contains statically linked native libraries and avoids loading the dynamic libraries. Can you please share which test(s) ran into the library loading issue? I'll see if I can reproduce the problem that you are running into. > > It was in fact not a problem. I was fooled by an error message. To be sure I was not loading any dynamically linked libraries, I removed the jdk/lib directory. Now the launcher failed, saying something like: > > "Error: Cannot locate dynamic library libjava.dylib". > > which was a bit of a jump scare. > > However, it turned out that it actually tried to load lib/jvm.cfg, and failed in loading this (since I had removed the entire lib directory), and this failure caused the above error message to be printed. When I restored lib/jvm.cfg (but not any dynamic libraries), the launcher worked. > Sounds like you are running into problems immediately during startup. Does the problem occur with just running bin/javastatic using a simple HelloWorld? Can you please send me your command line for reproducing? For the static Java support, I changed CreateExecutionEnvironment to return immediately if it executes statically. jvm.cfg is not loaded. Please see https://github.com/openjdk/leyden/blob/c1c5fc686c1452550e1b3663a320fba652248505/src/java.base/unix/native/libjli/java_md.c#L296. Sounds like the JLI_IsStaticJDK() check is not working properly in your case. Best, Jiangli > There are several bugs lurking here. For once, the error message is incorrect and should be corrected. Secondly, a statically linked launcher has just a single JVM included and should not have to look for the lib/jvm.cfg file at all. > > After looking around a bit in the launcher/jli code, my conclusion is that this code will need some additional care and loving attention to make it properly adjusted to function as a static launcher. We can't have a static launcher that tries to load a jvm.cfg file it does not need, and when it fails, complains that it is missing a dynamic library that it should not load. > > I'll try to get this fixed as part of my efforts to get the static launcher into mainline. >> >> This was done haphazardly in StaticLink.gmk in the hermetic-java-runtime >> branch, where an arbitrary subset of external libraries were hard-coded. >> Before integration in mainline can be possible, this information needs >> to be collected correctly and automatically for all included JDK >> libraries. Fortunately, it is not likely to be too hard. I basically >> just need to store the information from the LIBS provided to the >> NativeCompilation, and pick that up for all static libraries we include >> in the static launcher. (A complication is that we need to de-duplicate >> the list, and that some libraries are specified using two words, like >> "-framework Application" on macos, so it will take some care getting it >> right.) > > > Right, currently the hermetic-java-runtime branch specifies a list of hard-coded dependency libraries for linking. One of the goals of the hermetic prototype was avoiding/reducing refactoring/restructuring the existing code whenever possible. The reason is to reduce merge overhead when integrating with new changes from the mainline. We can do the proper refactoring and cleanups when getting the changes into the mainline. > > That is basically what I am doing right now. I am looking at your prototype and trying to reimplement this functionality properly so that it can be merged into mainline. The first step on that way was to actually get your prototype running. > > Now I have managed to get a version of your prototype that only includes the minimal set of changes needed to support the static launcher, and that works on mac and linux/gcc. Since your prototype is based on 586396cbb55a31 from March, I am trying to merge the patch with the latest master. This worked fine for macOS, but I hit some unexpected snag on Linux which I'm currently investigating. > > We have only briefly touched on the spec change topic (for the naming of native libraries) during the zoom meetings. I also agree that we should get that part started now. It's unclear to me if there's any existing blocker for that. > > I don't think there is. It's just that someone needs to step up and do it. > > /Magnus From duke at openjdk.org Fri Apr 26 04:25:00 2024 From: duke at openjdk.org (duke) Date: Fri, 26 Apr 2024 04:25:00 GMT Subject: git: openjdk/leyden: premain: Improved benchmarks docs; added "make compare_premain_builds" Message-ID: <132a4b61-b61f-4a30-a9ad-7d0ea2a033e9@openjdk.org> Changeset: 12ab8469 Author: iklam Date: 2024-04-25 21:24:12 +0000 URL: https://git.openjdk.org/leyden/commit/12ab8469c6a59fc86d61e9e099e3f3e4e2ddfc3b Improved benchmarks docs; added "make compare_premain_builds" ! test/hotspot/jtreg/premain/README.md + test/hotspot/jtreg/premain/lib/Bench.gmk ! test/hotspot/jtreg/premain/lib/DemoSupport.gmk ! test/hotspot/jtreg/premain/lib/GithubMDChart.java ! test/hotspot/jtreg/premain/spring-petclinic/Makefile From duke at openjdk.org Fri Apr 26 16:00:33 2024 From: duke at openjdk.org (duke) Date: Fri, 26 Apr 2024 16:00:33 GMT Subject: git: openjdk/leyden: premain: 152 new changesets Message-ID: Changeset: 90df3b7f Author: Mark Sheppard Date: 2024-04-16 15:44:15 +0000 URL: https://git.openjdk.org/leyden/commit/90df3b7fbb87f816f0bb688aa122cb3480399aee 8329190: (ch) DatagramChannel.receive should throw ClosedChannelException when called on closed channel Co-authored-by: Alan Bateman Reviewed-by: jpai, michaelm ! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/java.base/unix/classes/sun/nio/ch/SinkChannelImpl.java ! src/java.base/unix/classes/sun/nio/ch/SourceChannelImpl.java + test/jdk/java/nio/channels/Channels/ClosedNetworkChannels.java Changeset: 2ede1433 Author: Naoto Sato Date: 2024-04-16 16:04:43 +0000 URL: https://git.openjdk.org/leyden/commit/2ede14335a2c9133bf4f356189cfbd5839361d17 8330279: Typo in `java.text.Bidi` class description Reviewed-by: iris, joehw ! src/java.base/share/classes/java/text/Bidi.java Changeset: 941bee19 Author: Justin Lu Date: 2024-04-16 16:18:09 +0000 URL: https://git.openjdk.org/leyden/commit/941bee197ff679e9b8755cad117f5172e3508ef2 8327640: Allow NumberFormat strict parsing Reviewed-by: naoto ! src/java.base/share/classes/java/text/ChoiceFormat.java ! src/java.base/share/classes/java/text/CompactNumberFormat.java ! src/java.base/share/classes/java/text/DecimalFormat.java ! src/java.base/share/classes/java/text/Format.java ! src/java.base/share/classes/java/text/NumberFormat.java ! test/jdk/java/text/Format/CompactNumberFormat/TestEquality.java ! test/jdk/java/text/Format/CompactNumberFormat/serialization/TestSerialization.java + test/jdk/java/text/Format/DecimalFormat/EqualityTest.java + test/jdk/java/text/Format/DecimalFormat/SerializationTest.java + test/jdk/java/text/Format/NumberFormat/LenientParseTest.java + test/jdk/java/text/Format/NumberFormat/StrictMethodsTest.java + test/jdk/java/text/Format/NumberFormat/StrictParseTest.java Changeset: f7c84137 Author: Erik Gahlin Date: 2024-04-16 17:21:47 +0000 URL: https://git.openjdk.org/leyden/commit/f7c84137b5a1c9ce9878ff37a1f006a84b883b5e 8326116: JFR: Add help option to -XX:StartFlightRecording Reviewed-by: mgronlun ! src/hotspot/share/jfr/dcmd/jfrDcmds.cpp ! src/hotspot/share/jfr/dcmd/jfrDcmds.hpp ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/util/Utils.java + test/jdk/jdk/jfr/startupargs/TestStartHelp.java Changeset: 76cbe488 Author: Calvin Cheung Date: 2024-04-16 17:47:06 +0000 URL: https://git.openjdk.org/leyden/commit/76cbe4883b5f53843e5140eee2145011fec67e4c 8329430: MetaspaceShared::preload_and_dump should clear pending exception Reviewed-by: iklam, stuefe ! src/hotspot/share/cds/metaspaceShared.cpp Changeset: d1c6cd10 Author: Valerie Peng Date: 2024-04-16 22:47:02 +0000 URL: https://git.openjdk.org/leyden/commit/d1c6cd104ec117b88c45aafcb342164be4483f94 8330133: libj2pkcs11.so crashes on some pkcs#11 v3.0 libraries Reviewed-by: djelinski, weijun ! src/jdk.crypto.cryptoki/unix/native/libj2pkcs11/p11_md.c ! src/jdk.crypto.cryptoki/windows/native/libj2pkcs11/p11_md.c Changeset: fb4cf1cc Author: Alex Menkov Date: 2024-04-16 22:53:54 +0000 URL: https://git.openjdk.org/leyden/commit/fb4cf1cc3ce5957378516f4f6090d4c5d0f53e61 8329636: Deprecate -XX:+PreserveAllAnnotations Reviewed-by: coleenp, dholmes ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: f6f038a6 Author: Tom Rodriguez Date: 2024-04-17 00:18:15 +0000 URL: https://git.openjdk.org/leyden/commit/f6f038a678c450e1157247344fb0984c7bcaa11d 8317368: [JVMCI] SIGSEGV in JVMCIEnv::initialize_installed_code on libgraal Reviewed-by: dnsimon, kvn, eosterlund ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.hpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/jvmci/jvmciEnv.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp Changeset: c8702ede Author: Feilong Jiang Date: 2024-04-17 00:50:59 +0000 URL: https://git.openjdk.org/leyden/commit/c8702ede97437e0197340a559987ca321f67c15b 8330213: RISC-V: C2: assert(false) failed: bad AD file after JDK-8316991 Reviewed-by: fyang, rehn ! src/hotspot/cpu/riscv/riscv.ad Changeset: e57a322d Author: Erik Joelsson Date: 2024-04-17 00:51:11 +0000 URL: https://git.openjdk.org/leyden/commit/e57a322d7076474806458cc4b796bdb874e8e92e 8329970: Update autoconf build-aux files with latest from 2024-01-01 Reviewed-by: ihse, clanger ! make/autoconf/build-aux/autoconf-config.guess ! make/autoconf/build-aux/autoconf-config.sub Changeset: cd4c3aac Author: Gui Cao Committer: Fei Yang Date: 2024-04-17 01:34:39 +0000 URL: https://git.openjdk.org/leyden/commit/cd4c3aac63ddab3d3618df09787d6e9311454ff8 8330242: RISC-V: Simplify and remove CORRECT_COMPILER_ATOMIC_SUPPORT in atomic_linux_riscv.hpp Reviewed-by: fyang, rehn ! src/hotspot/os_cpu/linux_riscv/atomic_linux_riscv.hpp Changeset: 2fe2f3af Author: Ioi Lam Date: 2024-04-17 05:31:39 +0000 URL: https://git.openjdk.org/leyden/commit/2fe2f3aff82f41a3b7942861e29ccbd3bcc68661 8323900: Avoid calling os::init_random() in CDS static dump Reviewed-by: stuefe, ccheung ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveBuilder.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/oops/symbol.cpp Changeset: 01bda278 Author: Amit Kumar Date: 2024-04-17 06:34:31 +0000 URL: https://git.openjdk.org/leyden/commit/01bda278d6a498ca89c0bc5218680cd51a04e9d3 8330011: [s390x] update block-comments to make code consistent Reviewed-by: lucy ! src/hotspot/cpu/s390/downcallLinker_s390.cpp ! src/hotspot/cpu/s390/upcallLinker_s390.cpp Changeset: 9d63fee4 Author: Roberto Casta?eda Lozano Date: 2024-04-17 06:38:23 +0000 URL: https://git.openjdk.org/leyden/commit/9d63fee49c3b365e19cf492412a6b6d8c9633964 8330262: C2: simplify transfer of GC barrier data from Ideal to Mach nodes Reviewed-by: eosterlund, kvn ! src/hotspot/share/opto/matcher.cpp Changeset: 7744b004 Author: SendaoYan Committer: Severin Gehwolf Date: 2024-04-17 08:39:12 +0000 URL: https://git.openjdk.org/leyden/commit/7744b0046af4dbacb7068ae819d8a973cfbf8e40 8327946: containers/docker/TestJFREvents.java fails when host kernel config vm.swappiness=0 after JDK-8325139 Reviewed-by: sgehwolf ! test/hotspot/jtreg/containers/docker/TestJFREvents.java Changeset: 3ccbc6d4 Author: Yudi Zheng Committer: Doug Simon Date: 2024-04-17 09:08:50 +0000 URL: https://git.openjdk.org/leyden/commit/3ccbc6d4d014fb1ea92c47d270efd5f7ec05b0c3 8330280: SharedRuntime::get_resolved_entry should not return c2i entry if the callee is special native intrinsic Reviewed-by: pchilanomate, dlong ! src/hotspot/share/runtime/sharedRuntime.cpp Changeset: e4021adb Author: Per Minborg Date: 2024-04-17 09:26:26 +0000 URL: https://git.openjdk.org/leyden/commit/e4021adb287381a6c7775234b401429380075e0f 8330272: Wrong javadoc for ValueLayout.JAVA_LONG/JAVA_DOUBLE on x86 32bit Reviewed-by: mcimadamore, jvernee ! src/java.base/share/classes/java/lang/foreign/ValueLayout.java Changeset: 2885469c Author: Daniel Jeli?ski Committer: Jaikiran Pai Date: 2023-10-23 06:48:34 +0000 URL: https://git.openjdk.org/leyden/commit/2885469c4b9259d9218c845c9bebfdbfe27be784 8315708: Enhance HTTP/2 client usage Reviewed-by: rhalade, michaelm, dfuchs ! src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java Changeset: 0203c7e6 Author: Weijun Wang Committer: Jaikiran Pai Date: 2023-10-27 00:29:20 +0000 URL: https://git.openjdk.org/leyden/commit/0203c7e612126d85c7cd7a3bd55d948e130283a1 8318340: Improve RSA key implementations Reviewed-by: rhalade, mschoene, valeriep, mullan ! src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java ! src/java.base/share/classes/sun/security/rsa/RSAPrivateKeyImpl.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CKey.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CPrivateKey.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CPublicKey.java ! test/jdk/sun/security/pkcs11/PKCS11Test.java Changeset: 8de2f6f8 Author: David Holmes Committer: Jaikiran Pai Date: 2023-12-04 00:59:34 +0000 URL: https://git.openjdk.org/leyden/commit/8de2f6f883b319370f5959036ff7b1b6195e310d 8319851: Improve exception logging Reviewed-by: rhalade, matsaave, coleenp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/resolutionErrors.cpp ! src/hotspot/share/classfile/resolutionErrors.hpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/utilities/exceptions.cpp Changeset: 33d71275 Author: Christian Hagedorn Committer: Jaikiran Pai Date: 2024-02-09 12:38:12 +0000 URL: https://git.openjdk.org/leyden/commit/33d7127555a6782d718184dc2a00de2a7c4dcd20 8322122: Enhance generation of addresses Co-authored-by: Christian Hagedorn Co-authored-by: hedongbo Reviewed-by: rhalade, mschoene, dlong, thartmann ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp Changeset: d2f9a1eb Author: Jaikiran Pai Date: 2024-04-17 10:42:00 +0000 URL: https://git.openjdk.org/leyden/commit/d2f9a1eb9709dbd8b1e7b0d1c14b7876281d7f23 Merge Reviewed-by: dfuchs Changeset: 9445047d Author: Roland Westrelin Date: 2024-04-17 10:48:35 +0000 URL: https://git.openjdk.org/leyden/commit/9445047d059a87d49ed0923b438d2ec49340d78e 8330163: C2: improve CMoveNode::Value() when condition is always true or false Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/movenode.cpp + test/hotspot/jtreg/compiler/c2/irTests/TestCMoveCCP.java Changeset: 89129e3f Author: Jaikiran Pai Date: 2024-04-17 10:59:12 +0000 URL: https://git.openjdk.org/leyden/commit/89129e3f672d8af9613ad2a72e64322661836c96 8212895: ChronoField.INSTANT_SECONDS's range doesn't match the range of Instant Reviewed-by: rriggs, naoto ! src/java.base/share/classes/java/time/temporal/ChronoField.java ! test/jdk/java/time/tck/java/time/temporal/TCKChronoField.java Changeset: 5841cb3b Author: Magnus Ihse Bursie Date: 2024-04-17 12:39:36 +0000 URL: https://git.openjdk.org/leyden/commit/5841cb3b51e45e7c3aaa086e179815fa8184f22d 8330107: Separate out "awt" libraries from Awt2dLibraries.gmk Reviewed-by: erikj ! make/modules/java.desktop/Lib.gmk - make/modules/java.desktop/lib/Awt2dLibraries.gmk + make/modules/java.desktop/lib/AwtLibraries.gmk + make/modules/java.desktop/lib/ClientLibraries.gmk Changeset: 811aadd9 Author: Sonia Zaldana Calles Committer: Thomas Stuefe Date: 2024-04-17 12:54:12 +0000 URL: https://git.openjdk.org/leyden/commit/811aadd9e77356b294c9820e4d5aede81940537c 8324683: Unify AttachListener code for Posix platforms Reviewed-by: jsjolen, stuefe - src/hotspot/os/bsd/attachListener_bsd.cpp - src/hotspot/os/linux/attachListener_linux.cpp + src/hotspot/os/posix/attachListener_nix.cpp Changeset: ff3e76fd Author: Erik Gahlin Date: 2024-04-17 13:36:07 +0000 URL: https://git.openjdk.org/leyden/commit/ff3e76fd0caf6e5820d618e3e7b82a1a5d008070 8330053: JFR: Use LocalDateTime instead ZonedDateTime Reviewed-by: lmesnik, mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/Repository.java Changeset: 03e84178 Author: Maurizio Cimadamore Date: 2024-04-17 14:10:28 +0000 URL: https://git.openjdk.org/leyden/commit/03e84178ebfd2ca48b89d65d8f3c291e0c622fb5 8329948: Remove string template feature Reviewed-by: jlahoda ! src/java.base/share/classes/java/lang/StringConcatHelper.java - src/java.base/share/classes/java/lang/StringTemplate.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java - src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java - src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java - src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java - src/java.base/share/classes/java/lang/runtime/TemplateSupport.java - src/java.base/share/classes/java/util/FormatItem.java - src/java.base/share/classes/java/util/FormatProcessor.java ! src/java.base/share/classes/java/util/Formatter.java - src/java.base/share/classes/java/util/FormatterBuilder.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java - src/java.base/share/classes/jdk/internal/access/JavaTemplateAccess.java ! src/java.base/share/classes/jdk/internal/access/SharedSecrets.java ! src/java.base/share/classes/jdk/internal/util/DecimalDigits.java - src/java.base/share/classes/jdk/internal/util/Digits.java - src/java.base/share/classes/jdk/internal/util/FormatConcatItem.java ! src/java.base/share/classes/jdk/internal/util/HexDigits.java ! src/java.base/share/classes/jdk/internal/util/OctalDigits.java - src/jdk.compiler/share/classes/com/sun/source/tree/StringTemplateTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/CompileStates.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java - src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java - test/jdk/java/lang/String/concat/MakeConcatWithTemplate.java - test/jdk/java/lang/template/Basic.java - test/jdk/java/lang/template/FormatterBuilder.java - test/jdk/java/lang/template/StringTemplateTest.java - test/jdk/java/lang/template/T8313809.java ! test/langtools/jdk/jshell/CompletenessTest.java - test/langtools/tools/javac/diags/examples/StringTemplate.java - test/langtools/tools/javac/diags/examples/StringTemplateNoProcessor.java - test/langtools/tools/javac/diags/examples/StringTemplateNotProcessor.java - test/langtools/tools/javac/diags/examples/StringTemplateRawProcessor.java - test/langtools/tools/javac/diags/examples/StringTemplateUnclosedString.java - test/langtools/tools/javac/diags/examples/StringTemplateUnclosedTextBlock.java ! test/langtools/tools/javac/parser/JavacParserTest.java - test/langtools/tools/javac/template/Basic.java - test/langtools/tools/javac/template/T8312814.java - test/langtools/tools/javac/template/TreeScannerTest.java ! test/langtools/tools/javac/tree/TreeKindTest.java ! test/langtools/tools/jdeps/listdeps/ListModuleDeps.java - test/micro/org/openjdk/bench/java/lang/StringTemplateFMT.java Changeset: 192ec387 Author: Archie Cobbs Committer: Vicente Romero Date: 2024-04-17 14:31:40 +0000 URL: https://git.openjdk.org/leyden/commit/192ec387bc074b25465decf598a4dd87651cbcbb 8329595: spurious variable "might not have been initialized" on static final field Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java + test/langtools/tools/javac/DefiniteAssignment/StaticFinalNestedClass.java Changeset: 9fd78022 Author: Roland Westrelin Date: 2024-04-17 15:25:41 +0000 URL: https://git.openjdk.org/leyden/commit/9fd78022b19149ade40f92749f0b585ecfd41410 8325494: C2: Broken graph after not skipping CastII node anymore for Assertion Predicates after JDK-8309902 Reviewed-by: chagedorn, epeter ! src/hotspot/share/opto/loopTransform.cpp + test/hotspot/jtreg/compiler/predicates/TestAssertionPredicateDoesntConstantFold.java Changeset: fd331ff1 Author: Patricio Chilano Mateo Date: 2024-04-17 16:18:55 +0000 URL: https://git.openjdk.org/leyden/commit/fd331ff17330329a656181cb58714f1bd1623fcb 8325469: Freeze/Thaw code can crash in the presence of OSR frames Reviewed-by: rpressler, dlong ! src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp ! src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp ! src/hotspot/cpu/ppc/frame_ppc.inline.hpp ! src/hotspot/cpu/ppc/stackChunkFrameStream_ppc.inline.hpp ! src/hotspot/cpu/riscv/frame_riscv.inline.hpp ! src/hotspot/cpu/riscv/stackChunkFrameStream_riscv.inline.hpp ! src/hotspot/cpu/x86/frame_x86.inline.hpp ! src/hotspot/cpu/x86/stackChunkFrameStream_x86.inline.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/oops/stackChunkOop.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/stackChunkFrameStream.inline.hpp + test/jdk/jdk/internal/vm/Continuation/OSRTest.java Changeset: 4895a15a Author: Suchismith Roy Committer: Martin Doerr Date: 2024-04-17 17:03:40 +0000 URL: https://git.openjdk.org/leyden/commit/4895a15a779fab70290b4df3b464d79a14937e28 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object Reviewed-by: mdoerr, mchung + src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java + test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java Changeset: 06462847 Author: Archie Cobbs Committer: Vicente Romero Date: 2024-04-17 17:35:17 +0000 URL: https://git.openjdk.org/leyden/commit/064628471b83616b4463baa78618d1b7a66d0c7c 8317376: Minor improvements to the 'this' escape analyzer Reviewed-by: vromero ! make/CompileModuleTools.gmk - make/modules/java.net.http/Java.gmk ! make/modules/java.sql.rowset/Java.gmk ! make/modules/jdk.charsets/Java.gmk ! make/modules/jdk.compiler/Gendata.gmk - make/modules/jdk.crypto.ec/Java.gmk ! make/modules/jdk.javadoc/Gendata.gmk ! make/modules/jdk.jcmd/Java.gmk ! make/modules/jdk.jconsole/Java.gmk ! make/modules/jdk.jdeps/Gensrc.gmk ! make/modules/jdk.jdeps/Launcher.gmk ! make/modules/jdk.jdi/Java.gmk ! make/modules/jdk.jpackage/Java.gmk ! make/modules/jdk.localedata/Java.gmk ! make/modules/jdk.sctp/Java.gmk ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/langtools/tools/javac/warnings/ThisEscape.java ! test/langtools/tools/javac/warnings/ThisEscape.out Changeset: fe0227e9 Author: Ioi Lam Date: 2024-04-18 03:35:15 +0000 URL: https://git.openjdk.org/leyden/commit/fe0227e97858be15bda813dba42ab466123aee1f 8311098: Change comment in verificationType.hpp to refer to _sym Reviewed-by: ccheung ! src/hotspot/share/classfile/verificationType.hpp Changeset: 706b421c Author: Adam Sotona Date: 2024-04-18 05:50:24 +0000 URL: https://git.openjdk.org/leyden/commit/706b421ccaff2129512ee3ea15ef1d6c264cbe01 8330467: NoClassDefFoundError when lambda is in a hidden class Reviewed-by: psandoz, mchung ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java + test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenLambda.java Changeset: 003e86fe Author: Soumadipta Roy Committer: Aleksey Shipilev Date: 2024-04-18 07:57:11 +0000 URL: https://git.openjdk.org/leyden/commit/003e86fe38ca1b809418f6282336e259862d0776 8324755: Enable parallelism in vmTestbase/gc/gctests/LargeObjects tests Reviewed-by: shade, lmesnik - test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large001/TEST.properties - test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large002/TEST.properties - test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large003/TEST.properties - test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large004/TEST.properties - test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large005/TEST.properties Changeset: 5eb2c596 Author: Albert Mingkun Yang Date: 2024-04-18 08:25:19 +0000 URL: https://git.openjdk.org/leyden/commit/5eb2c596e2ca38025dfb9f8e37703036d0bcda19 8330475: Remove unused default value for ModRefBarrierSet::write_ref_array_pre Reviewed-by: gli, tschatzl ! src/hotspot/share/gc/shared/modRefBarrierSet.hpp Changeset: 4b55fe57 Author: Matthias Baesken Date: 2024-04-18 10:03:41 +0000 URL: https://git.openjdk.org/leyden/commit/4b55fe577701317e6570f045ed9fe28aa97fc7ea 8330520: linux clang build fails in os_linux.cpp with static_assert with no message is a C++17 extension Reviewed-by: stefank, mdoerr ! src/hotspot/os/linux/os_linux.cpp Changeset: b0496096 Author: Hamlin Li Date: 2024-04-18 11:13:10 +0000 URL: https://git.openjdk.org/leyden/commit/b0496096dc8d7dc7acf28aa006141a3ecea446de 8330094: RISC-V: Save and restore FRM in the call stub Reviewed-by: fyang, luhenry ! src/hotspot/cpu/riscv/frame_riscv.hpp ! src/hotspot/cpu/riscv/riscv_v.ad ! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp Changeset: 60b65e60 Author: Coleen Phillimore Date: 2024-04-18 11:21:39 +0000 URL: https://git.openjdk.org/leyden/commit/60b65e60906026b3cd5e8829c464a31df5898bdc 8325872: Make GuaranteedSafepointInterval default 0 Reviewed-by: shade, eosterlund, dcubed ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/monitorDeflationThread.cpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/runtime/vmThread.hpp Changeset: b648ed0a Author: Per Minborg Date: 2024-04-18 11:22:47 +0000 URL: https://git.openjdk.org/leyden/commit/b648ed0a08b5ed47c1a7d7cbca89d8f389b17013 8329997: Add provisions for checking memory segment alignment constraints Reviewed-by: jvernee, mcimadamore ! src/java.base/share/classes/java/lang/foreign/MemorySegment.java ! src/java.base/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java ! src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java ! test/jdk/java/foreign/TestMemoryAlignment.java Changeset: 5853a2c0 Author: Erik Gahlin Date: 2024-04-18 11:59:57 +0000 URL: https://git.openjdk.org/leyden/commit/5853a2c00983028bab684241f428820587186a4e 8330533: JFR: LocalDateTime should not use milliseconds since epoch Reviewed-by: aturbanov, mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/Repository.java Changeset: 571e6bc3 Author: Fei Yang Date: 2024-04-18 12:48:24 +0000 URL: https://git.openjdk.org/leyden/commit/571e6bc3f7d521d3be7ee1c6c32705c768645b75 8330419: Unused code in ConnectionGraph::specialize_castpp Reviewed-by: chagedorn ! src/hotspot/share/opto/escape.cpp Changeset: ec180d47 Author: Tobias Holenstein Date: 2024-04-18 12:53:47 +0000 URL: https://git.openjdk.org/leyden/commit/ec180d4782d39d50d2db3dfbe78e62a215c0a414 8324950: IGV: save the state to a file Reviewed-by: rcastanedalo, chagedorn ! src/utils/IdealGraphVisualizer/Coordinator/pom.xml ! src/utils/IdealGraphVisualizer/Coordinator/src/main/java/com/sun/hotspot/igv/coordinator/OutlineTopComponent.java ! src/utils/IdealGraphVisualizer/Coordinator/src/main/java/com/sun/hotspot/igv/coordinator/actions/ImportAction.java + src/utils/IdealGraphVisualizer/Coordinator/src/main/java/com/sun/hotspot/igv/coordinator/actions/OpenAction.java ! src/utils/IdealGraphVisualizer/Coordinator/src/main/java/com/sun/hotspot/igv/coordinator/actions/RemoveAction.java ! src/utils/IdealGraphVisualizer/Coordinator/src/main/java/com/sun/hotspot/igv/coordinator/actions/RemoveAllAction.java + src/utils/IdealGraphVisualizer/Coordinator/src/main/java/com/sun/hotspot/igv/coordinator/actions/SaveAction.java - src/utils/IdealGraphVisualizer/Coordinator/src/main/java/com/sun/hotspot/igv/coordinator/actions/SaveAllAction.java ! src/utils/IdealGraphVisualizer/Coordinator/src/main/java/com/sun/hotspot/igv/coordinator/actions/SaveAsAction.java ! src/utils/IdealGraphVisualizer/Coordinator/src/main/resources/com/sun/hotspot/igv/coordinator/Bundle.properties ! src/utils/IdealGraphVisualizer/Coordinator/src/main/resources/com/sun/hotspot/igv/coordinator/actions/Bundle.properties ! src/utils/IdealGraphVisualizer/Coordinator/src/main/resources/com/sun/hotspot/igv/coordinator/images/import.png + src/utils/IdealGraphVisualizer/Coordinator/src/main/resources/com/sun/hotspot/igv/coordinator/images/open.png = src/utils/IdealGraphVisualizer/Coordinator/src/main/resources/com/sun/hotspot/igv/coordinator/images/save_as.gif ! src/utils/IdealGraphVisualizer/Coordinator/src/main/resources/com/sun/hotspot/igv/coordinator/layer.xml ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/Folder.java ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/FolderElement.java ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/GraphDocument.java ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/Group.java ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/serialization/Parser.java ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/serialization/Printer.java ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/services/GraphViewer.java - src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/services/GroupCallback.java ! src/utils/IdealGraphVisualizer/Data/src/test/java/com/sun/hotspot/igv/data/serialization/ParserTest.java - src/utils/IdealGraphVisualizer/NetworkConnection/src/main/java/com/sun/hotspot/igv/connection/Client.java ! src/utils/IdealGraphVisualizer/NetworkConnection/src/main/java/com/sun/hotspot/igv/connection/Server.java ! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/DiagramScene.java ! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/DiagramViewModel.java ! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/EditorTopComponent.java ! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/GraphViewerImplementation.java Changeset: f713766c Author: Renjith Kannath Pariyangad Committer: Alexey Ivanov Date: 2024-04-18 13:32:35 +0000 URL: https://git.openjdk.org/leyden/commit/f713766cab649947e543f0290717e7bcc501f063 8329322: Convert PageFormat/Orient.java to use PassFailJFrame Reviewed-by: abhiscxk, aivanov ! test/jdk/java/awt/print/PageFormat/Orient.java Changeset: 235ba9a7 Author: Joe Darcy Date: 2024-04-18 16:12:50 +0000 URL: https://git.openjdk.org/leyden/commit/235ba9a7025964b1e43149c7102e26b82b2081ad 8330458: Add missing @since tag to ClassFile.JAVA_23_VERSION Reviewed-by: jjg, iris, asotona ! src/java.base/share/classes/java/lang/classfile/ClassFile.java Changeset: 6ee84077 Author: Jonathan Gibbons Date: 2024-04-18 18:49:08 +0000 URL: https://git.openjdk.org/leyden/commit/6ee8407758c92d32e18642b0758d2d5c71ad09f5 8324342: Doclet should default @since for a nested class to that of its enclosing class Reviewed-by: prappo, hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/SimpleTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/TagletManager.java ! src/jdk.javadoc/share/man/javadoc.1 ! test/langtools/jdk/javadoc/doclet/testAuthor/TestAuthor.java ! test/langtools/jdk/javadoc/doclet/testSinceTag/TestSinceTag.java ! test/langtools/jdk/javadoc/doclet/testVersionTag/TestVersionTag.java Changeset: 32946e18 Author: Alexey Semenyuk Date: 2024-04-18 22:09:32 +0000 URL: https://git.openjdk.org/leyden/commit/32946e1882e9b22c983cbba3c6bda3cc7295946a 8295111: dpkg appears to have problems resolving symbolically linked native libraries Reviewed-by: almatvee ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java Changeset: 252c62a6 Author: Matthias Baesken Date: 2024-04-19 10:02:44 +0000 URL: https://git.openjdk.org/leyden/commit/252c62a66dd955a5d22f307544f38cc0dd4f2550 8330524: Linux ppc64le compile warning with clang in os_linux_ppc.cpp Reviewed-by: mdoerr, clanger ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp Changeset: 46a2ce4e Author: Hannes Walln?fer Date: 2024-04-19 10:03:59 +0000 URL: https://git.openjdk.org/leyden/commit/46a2ce4eb4c961649a70d52a6317a2c022e87d63 8330063: Upgrade jQuery to 3.7.1 Reviewed-by: prappo - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-3.6.1.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-3.6.1.min.js + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-3.7.1.js + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-3.7.1.min.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! src/jdk.javadoc/share/legal/jquery.md ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/langtools/jdk/javadoc/doclet/testSearchScript/javadoc-search.js ! test/langtools/jdk/javadoc/tool/api/basic/APITest.java Changeset: 8990864a Author: Robbin Ehn Date: 2024-04-19 10:05:24 +0000 URL: https://git.openjdk.org/leyden/commit/8990864a53fa04f44ecf8bff65a6dc9cdd67cb1c 8330156: RISC-V: Range check auipc + signed 12 imm instruction Reviewed-by: fyang, mli, tonyp ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp Changeset: 9f2a4fad Author: Jaikiran Pai Date: 2024-04-19 10:07:25 +0000 URL: https://git.openjdk.org/leyden/commit/9f2a4fad1715ccbc339d2476bbdc7a52e9a13380 8330572: jdk.internal.net.http.HttpConnection calls an expensive checkOpen() when returning a HTTP/1.1 connection to the pool Reviewed-by: dfuchs, djelinski ! src/java.net.http/share/classes/jdk/internal/net/http/HttpConnection.java Changeset: 85261bce Author: Hamlin Li Date: 2024-04-19 10:08:57 +0000 URL: https://git.openjdk.org/leyden/commit/85261bcebc1903d9f05523bfb9c1b25d7f1fd8b6 8330266: RISC-V: Restore frm to RoundingMode::rne after JNI Reviewed-by: fyang, rehn ! src/hotspot/cpu/riscv/downcallLinker_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp Changeset: eb60822a Author: Abhishek Kumar Date: 2024-04-19 10:10:00 +0000 URL: https://git.openjdk.org/leyden/commit/eb60822a45ecd076484e707b2dd1049ed9d8079b 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and disabled ComboBox does not match in these LAFs: GTK+ Reviewed-by: dnguyen, jdv, tr, serb ! test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTestAuto.java Changeset: 177092b9 Author: Johan Sj?len Date: 2024-04-19 10:13:40 +0000 URL: https://git.openjdk.org/leyden/commit/177092b952c2135c6f6872c6b64d1e210452d35a 8330569: Rename Nix to Posix in platform-dependent attachListener code Reviewed-by: mdoerr, stuefe, coleenp = src/hotspot/os/posix/attachListener_posix.cpp Changeset: 650ca65a Author: Erik Gahlin Date: 2024-04-19 14:50:39 +0000 URL: https://git.openjdk.org/leyden/commit/650ca65a4f838a1095e43acac649fde48eceaee7 8329330: NoClassDefFoundError: Could not initialize class jdk.jfr.internal.MirrorEvents Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java Changeset: 3c1d1d93 Author: Dan Heidinga Committer: Coleen Phillimore Date: 2024-04-19 15:03:18 +0000 URL: https://git.openjdk.org/leyden/commit/3c1d1d93d7b1de229753ed697f008bd5639ac957 8320522: Remove code related to `RegisterFinalizersAtInit` Reviewed-by: coleenp, ayang, kbarrett ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/riscv/templateTable_riscv.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/interpreter/abstractInterpreter.cpp ! src/hotspot/share/interpreter/rewriter.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: 8da175d0 Author: Amit Kumar Date: 2024-04-19 16:06:55 +0000 URL: https://git.openjdk.org/leyden/commit/8da175d094c02e7655188a60e6364104433429de 8330008: [s390x] Test bit "in-memory" in case of DiagnoseSyncOnValueBasedClasses Reviewed-by: lucy, mdoerr ! src/hotspot/cpu/s390/macroAssembler_s390.cpp ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp Changeset: b704e912 Author: Vladimir Kozlov Date: 2024-04-19 16:11:17 +0000 URL: https://git.openjdk.org/leyden/commit/b704e91241b0f84d866f50a8f2c6af240087cb29 8329433: Reduce nmethod header size Reviewed-by: dlong, iveresov ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/code/debugInfoRec.cpp ! src/hotspot/share/code/dependencies.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compilerDefinitions.hpp ! src/hotspot/share/gc/shared/classUnloadingContext.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/memory/heap.hpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java Changeset: c1dd82b4 Author: Joe Darcy Date: 2024-04-19 19:00:17 +0000 URL: https://git.openjdk.org/leyden/commit/c1dd82b4d2393b2095cfd2365a806b74e9adf92e 8329644: Discuss expected visitor evolution patterns in javax.lang.model.util Reviewed-by: prappo, jlahoda, jjg ! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScannerPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/package-info.java Changeset: df043582 Author: Jonathan Gibbons Date: 2024-04-19 19:02:46 +0000 URL: https://git.openjdk.org/leyden/commit/df04358223e8ae24009187d9c5a7e12701f4191f 8330179: Clean up non-standard use of /** comments in `jdk.compiler` Reviewed-by: darcy ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java Changeset: f6feeb03 Author: Joe Darcy Date: 2024-04-19 20:32:18 +0000 URL: https://git.openjdk.org/leyden/commit/f6feeb03bbe9024b609ae6a4795255128581d53c 8330703: Improve link syntax in javax.lang.model.util Reviewed-by: jjg ! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScannerPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitorPreview.java Changeset: 6d569961 Author: Ioi Lam Date: 2024-04-20 03:52:17 +0000 URL: https://git.openjdk.org/leyden/commit/6d5699617ff0985104a8bb5f2c9eb8887cb0961e 8330540: Rename the enum type CompileCommand to CompileCommandEnum Reviewed-by: kvn, dlong ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compilerDirectives.cpp ! src/hotspot/share/compiler/compilerDirectives.hpp ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/compiler/compilerOracle.hpp ! src/hotspot/share/compiler/methodMatcher.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/oops/methodCounters.cpp ! src/hotspot/share/oops/methodCounters.hpp ! src/hotspot/share/oops/methodData.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/utilities/vmEnums.hpp Changeset: 185e711b Author: Jatin Bhateja Date: 2024-04-21 23:21:17 +0000 URL: https://git.openjdk.org/leyden/commit/185e711bfe4c4d013b56e867f85cfb4177b3a2cf 8318650: Optimized subword gather for x86 targets. Reviewed-by: sviswanathan, epeter, psandoz ! src/hotspot/cpu/aarch64/aarch64_vector.ad ! src/hotspot/cpu/aarch64/matcher_aarch64.hpp ! src/hotspot/cpu/arm/matcher_arm.hpp ! src/hotspot/cpu/ppc/matcher_ppc.hpp ! src/hotspot/cpu/riscv/matcher_riscv.hpp ! src/hotspot/cpu/riscv/riscv_v.ad ! src/hotspot/cpu/s390/matcher_s390.hpp ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/matcher_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/matcher.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/opto/vectornode.hpp ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template + test/micro/org/openjdk/bench/jdk/incubator/vector/GatherOperationsBenchmark.java Changeset: bd67ac69 Author: Scott Gibbons Committer: Jatin Bhateja Date: 2024-04-21 23:24:46 +0000 URL: https://git.openjdk.org/leyden/commit/bd67ac69a234cd1096e534c7d4a45d88715884b4 8329331: Intrinsify Unsafe::setMemory Reviewed-by: sviswanathan, jbhateja, kvn ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/arm/stubGenerator_arm.cpp ! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp ! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp ! src/hotspot/cpu/zero/stubGenerator_zero.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp ! src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp ! src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp ! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp ! src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp ! src/hotspot/os_cpu/linux_riscv/os_linux_riscv.cpp ! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/runtime.hpp ! src/hotspot/share/prims/unsafe.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/stubRoutines.cpp ! src/hotspot/share/runtime/stubRoutines.hpp ! src/hotspot/share/utilities/copy.cpp ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java + test/micro/org/openjdk/bench/java/lang/foreign/MemorySegmentZeroUnsafe.java Changeset: 20546c1e Author: Christian Hagedorn Date: 2024-04-22 06:07:07 +0000 URL: https://git.openjdk.org/leyden/commit/20546c1ea064daa8e2faa71142904ea2c62b3311 8330004: Refactor cloning down code in Split If for Template Assertion Predicates Reviewed-by: epeter, kvn ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/predicates.cpp ! src/hotspot/share/opto/predicates.hpp ! src/hotspot/share/opto/split_if.cpp + test/hotspot/jtreg/compiler/predicates/assertion/TestSplitIfCloningDown.java Changeset: 5394f57f Author: Evgeny Nikitin Committer: Tobias Hartmann Date: 2024-04-22 07:41:06 +0000 URL: https://git.openjdk.org/leyden/commit/5394f57f002c066021d811382a336253ae9f2014 8330621: Make 5 compiler tests use ProcessTools.executeProcess Reviewed-by: chagedorn, stefank, thartmann ! test/hotspot/jtreg/compiler/c2/Test7068051.java ! test/hotspot/jtreg/compiler/c2/unloaded/TestInlineUnloaded.java ! test/hotspot/jtreg/compiler/jsr292/NonInlinedCall/Agent.java ! test/hotspot/jtreg/compiler/profiling/spectrapredefineclass/Launcher.java ! test/hotspot/jtreg/compiler/profiling/spectrapredefineclass_classloaders/Launcher.java Changeset: 5313dcc8 Author: Guoxiong Li Date: 2024-04-22 08:14:53 +0000 URL: https://git.openjdk.org/leyden/commit/5313dcc8f9c5bf54a2a44a1d68a690f13f15882a 8330733: Generational ZGC: Remove ZBarrier::verify_old_object_live_slow_path Reviewed-by: stefank, tschatzl ! src/hotspot/share/gc/z/zBarrier.cpp ! src/hotspot/share/gc/z/zBarrier.hpp Changeset: 3d62bbf4 Author: Claes Redestad Date: 2024-04-22 08:54:29 +0000 URL: https://git.openjdk.org/leyden/commit/3d62bbf4f2ea1b37d59c8307225239a88d9e66c0 8330681: Explicit hashCode and equals for java.lang.runtime.SwitchBootstraps$TypePairs Reviewed-by: jlahoda, mchung ! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java Changeset: 35b30c81 Author: Claes Redestad Date: 2024-04-22 08:55:46 +0000 URL: https://git.openjdk.org/leyden/commit/35b30c81e0153a12881e622b861ee38c8166ef72 8330595: Invoke ObjectMethods::bootstrap method exactly Reviewed-by: mchung ! src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java Changeset: 70acade9 Author: Guoxiong Li Date: 2024-04-22 08:58:38 +0000 URL: https://git.openjdk.org/leyden/commit/70acade9f1bd0c7bba25abad0f0d8199715d66d0 8330339: G1: Move some public methods to private in G1BlockOffsetTable APIs Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp Changeset: c4f5c514 Author: Jonas Norlinder Committer: Erik ?sterlund Date: 2024-04-22 09:00:24 +0000 URL: https://git.openjdk.org/leyden/commit/c4f5c5140a85818152c6e17414a36deabe491f7b 8330576: ZYoungCompactionLimit should have range check Reviewed-by: eosterlund, stefank ! src/hotspot/share/gc/z/z_globals.hpp Changeset: f889797e Author: Albert Mingkun Yang Date: 2024-04-22 10:05:32 +0000 URL: https://git.openjdk.org/leyden/commit/f889797e1fa6bc3824d97912643a33696d367af3 8330463: Rename invalidate() to write_region() in ModRefBarrierSet Reviewed-by: gli, tschatzl ! src/hotspot/share/gc/g1/g1BarrierSet.cpp ! src/hotspot/share/gc/g1/g1BarrierSet.hpp ! src/hotspot/share/gc/g1/g1BarrierSet.inline.hpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.cpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.hpp ! src/hotspot/share/gc/shared/modRefBarrierSet.hpp ! src/hotspot/share/gc/shared/modRefBarrierSet.inline.hpp Changeset: 3e185c70 Author: Albert Mingkun Yang Date: 2024-04-22 10:08:52 +0000 URL: https://git.openjdk.org/leyden/commit/3e185c70feef3febf75c58a5d4d394a4b772105f 8330154: Serial: Remove TenuredSpace::update_for_block Reviewed-by: gli, tschatzl ! src/hotspot/share/gc/serial/serialFullGC.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.inline.hpp ! src/hotspot/share/gc/shared/space.hpp ! src/hotspot/share/gc/shared/space.inline.hpp Changeset: ee7b2e9b Author: Coleen Phillimore Date: 2024-04-22 11:25:53 +0000 URL: https://git.openjdk.org/leyden/commit/ee7b2e9b3bd2b4607476ae03bb6c9f7e49a43d0e 8330051: Small ObjectMonitor spinning code cleanups Reviewed-by: dcubed, eosterlund, fbredberg ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp Changeset: 936a47d7 Author: Coleen Phillimore Date: 2024-04-22 11:40:22 +0000 URL: https://git.openjdk.org/leyden/commit/936a47d7d68c7305993f68db844dc76006b674b1 8330607: Deprecate -XX:+UseEmptySlotsInSupers Reviewed-by: shade, dcubed ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: 3e65d90b Author: Magnus Ihse Bursie Date: 2024-04-22 13:32:02 +0000 URL: https://git.openjdk.org/leyden/commit/3e65d90b4ddb52878ebdc2150790c0333b9c0920 8330820: Remove remnants of operator_new.cpp in build system Reviewed-by: tbell ! make/hotspot/lib/CompileGtest.gmk ! make/hotspot/lib/CompileJvm.gmk Changeset: 7e421ce9 Author: Roman Kennke Date: 2024-04-22 15:03:09 +0000 URL: https://git.openjdk.org/leyden/commit/7e421ce9d089ce3e36336fca0f603bcbfbbda6c5 8330585: Refactor/rename forwardee handling Reviewed-by: stefank, ayang ! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp ! src/hotspot/share/gc/shared/preservedMarks.inline.hpp ! src/hotspot/share/oops/markWord.hpp ! src/hotspot/share/oops/oop.inline.hpp Changeset: 20be5e09 Author: Ioi Lam Date: 2024-04-22 15:53:14 +0000 URL: https://git.openjdk.org/leyden/commit/20be5e095f85d92215df68bb6eeb621b4ed249a1 8314846: Do not store Klass::_secondary_super_cache in CDS archive Reviewed-by: stuefe, aph ! src/hotspot/share/oops/klass.cpp Changeset: 0b9350e8 Author: Vicente Romero Date: 2024-04-22 16:31:32 +0000 URL: https://git.openjdk.org/leyden/commit/0b9350e8b619bc556f36652cde6f73211be5b85b 8322992: Javac fails with StackOverflowError when compiling deeply nested synchronized blocks Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java + test/langtools/tools/javac/patterns/SOEDeeplyNestedBlocksTest.java Changeset: 83c74d73 Author: Nizar Benalla Committer: Jonathan Gibbons Date: 2024-04-22 20:36:43 +0000 URL: https://git.openjdk.org/leyden/commit/83c74d7307e258441abb171552e953f1c6d9b98a 8329717: Missing `@since` tags in elements in DocumentationTool and Taglet Reviewed-by: prappo ! src/java.compiler/share/classes/javax/tools/DocumentationTool.java ! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Taglet.java Changeset: 1d52234e Author: Jonathan Gibbons Date: 2024-04-22 21:52:22 +0000 URL: https://git.openjdk.org/leyden/commit/1d52234e199c7a38c059c0aa88aea2910f749d48 8330704: Clean up non-standard use of /** comments in some langtools tests Reviewed-by: iris ! test/langtools/jdk/javadoc/tool/EnablePreviewOption.java ! test/langtools/jdk/javadoc/tool/ReleaseOption.java ! test/langtools/jdk/javadoc/tool/T4696488.java ! test/langtools/jdk/javadoc/tool/T4994049/T4994049.java ! test/langtools/jdk/javadoc/tool/T6551367.java ! test/langtools/jdk/javadoc/tool/TestScriptInComment.java ! test/langtools/jdk/javadoc/tool/modules/CommandLineFiles.java ! test/langtools/jdk/javadoc/tool/modules/FilterOptions.java ! test/langtools/jdk/javadoc/tool/modules/PackageOptions.java ! test/langtools/jdk/javadoc/tool/modules/PatchModules.java ! test/langtools/jdk/javadoc/tool/modules/ReleaseOptions.java ! test/langtools/jdk/javadoc/tool/nonConstExprs/Test.java ! test/langtools/jdk/javadoc/tool/parser/7091528/T7091528.java ! test/langtools/jdk/jshell/HighlightUITest.java ! test/langtools/jdk/jshell/HistoryUITest.java ! test/langtools/jdk/jshell/IndentUITest.java ! test/langtools/jdk/jshell/PasteAndMeasurementsUITest.java ! test/langtools/jdk/jshell/ToolMultilineSnippetHistoryTest.java ! test/langtools/jdk/jshell/ToolShiftTabTest.java ! test/langtools/jdk/jshell/ToolTabCommandTest.java ! test/langtools/jdk/jshell/ToolTabSnippetTest.java ! test/langtools/jdk/jshell/UndefinedClassTest.java Changeset: 58ad399d Author: Scott Gibbons Committer: Sandhya Viswanathan Date: 2024-04-22 22:54:19 +0000 URL: https://git.openjdk.org/leyden/commit/58ad399d196bf2dd701df451004b7815b0820675 8330821: Rename UnsafeCopyMemory Reviewed-by: kvn, sviswanathan ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/arm/stubGenerator_arm.cpp ! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp ! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp ! src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp ! src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp ! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp ! src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp ! src/hotspot/os_cpu/linux_riscv/os_linux_riscv.cpp ! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp ! src/hotspot/share/runtime/stubRoutines.cpp ! src/hotspot/share/runtime/stubRoutines.hpp Changeset: 57ebd045 Author: Roberto Casta?eda Lozano Date: 2024-04-23 04:18:23 +0000 URL: https://git.openjdk.org/leyden/commit/57ebd045eae8ef1bdb5ec96d5eb11d252e08e6bb 8330153: C2: dump barrier information for all Mach nodes Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/machnode.cpp ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/examples/GCBarrierIRExample.java Changeset: 550a1386 Author: Nizar Benalla Committer: Jaikiran Pai Date: 2024-04-23 05:54:50 +0000 URL: https://git.openjdk.org/leyden/commit/550a1386222462cca10f79a66453d2f08431dfdf 8306928: Duplicate variable assignement in jdk.internal.net.http.AuthenticationFilter#getCredentials Reviewed-by: clanger, jpai ! src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.java Changeset: 574ba140 Author: Roberto Casta?eda Lozano Date: 2024-04-23 06:52:58 +0000 URL: https://git.openjdk.org/leyden/commit/574ba1400e015bf579190828fbdf0618eed48bdf 8330862: GCBarrierIRExample fails when a different GC is selected via the command line Reviewed-by: thartmann, dholmes, stefank ! test/hotspot/jtreg/testlibrary_tests/ir_framework/examples/GCBarrierIRExample.java Changeset: 89610770 Author: Nizar Benalla Committer: Jaikiran Pai Date: 2024-04-23 07:18:52 +0000 URL: https://git.openjdk.org/leyden/commit/896107705615a3b9363b7a0a3e6703b20fedef70 8309259: Reduce calls to MethodHandles.lookup() in jdk.internal.net.http.Stream Reviewed-by: pminborg, jpai ! src/java.net.http/share/classes/jdk/internal/net/http/Stream.java Changeset: daa5a4bd Author: Claes Redestad Date: 2024-04-23 08:00:07 +0000 URL: https://git.openjdk.org/leyden/commit/daa5a4bd124d539daa3c67a3e29dcd0eee20c44d 8330802: Desugar switch in Locale::createLocale Reviewed-by: alanb, liach, rriggs, naoto, mchung ! src/java.base/share/classes/java/util/Locale.java Changeset: 281f9bde Author: Feilong Jiang Date: 2024-04-23 08:00:18 +0000 URL: https://git.openjdk.org/leyden/commit/281f9bdeb9d6870346b12e6c62a58f7984b1b133 8330735: RISC-V: No need to move sp to tmp register in set_last_Java_frame Reviewed-by: fyang ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp Changeset: 1a6da3d5 Author: Albert Mingkun Yang Date: 2024-04-23 11:05:23 +0000 URL: https://git.openjdk.org/leyden/commit/1a6da3d5f0ac57e173340a117a9368c190a34e8b 8330822: Remove ModRefBarrierSet::write_ref_array_work Reviewed-by: gli, tschatzl ! src/hotspot/share/gc/g1/g1BarrierSet.hpp ! src/hotspot/share/gc/g1/g1BarrierSet.inline.hpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.cpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.hpp ! src/hotspot/share/gc/shared/modRefBarrierSet.hpp ! src/hotspot/share/gc/shared/modRefBarrierSet.inline.hpp Changeset: d9d926d6 Author: Albert Mingkun Yang Date: 2024-04-23 11:05:35 +0000 URL: https://git.openjdk.org/leyden/commit/d9d926d6699b7b2e1fcce206cbe03e1de661c2ac 8330145: Serial: Refactor SerialHeap::scan_evacuated_objs Reviewed-by: gli, tschatzl ! src/hotspot/share/gc/serial/cardTableRS.cpp ! src/hotspot/share/gc/serial/cardTableRS.hpp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp - src/hotspot/share/gc/serial/defNewGeneration.inline.hpp ! src/hotspot/share/gc/serial/generation.hpp ! src/hotspot/share/gc/serial/serialFullGC.cpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/gc/serial/serialHeap.inline.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.inline.hpp Changeset: 3bd6982e Author: Adam Sotona Date: 2024-04-23 11:07:58 +0000 URL: https://git.openjdk.org/leyden/commit/3bd6982ec3dd48970450cc0da9c25d755924f449 8326150: Typo in the documentation for jdk.jshell Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/module-info.java Changeset: fcb4a8ba Author: Coleen Phillimore Date: 2024-04-23 11:31:11 +0000 URL: https://git.openjdk.org/leyden/commit/fcb4a8ba26fe1de596331b0a2f89c5c7c24e7f9e 8330578: The VM creates instance of abstract class VirtualMachineError Reviewed-by: iklam, dlong, jwaters, dholmes ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/verifier.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp Changeset: a92ad039 Author: Jaroslav Bachorik Date: 2024-04-23 12:14:57 +0000 URL: https://git.openjdk.org/leyden/commit/a92ad03946d296510c8c2ac18278608e8032b3f3 8329995: Restricted access to `/proc` can cause JFR initialization to crash Reviewed-by: dholmes, egahlin ! src/hotspot/os/linux/os_perf_linux.cpp Changeset: 6158da5e Author: Oli Gillespie Committer: Aleksey Shipilev Date: 2024-04-23 12:37:36 +0000 URL: https://git.openjdk.org/leyden/commit/6158da5e9569f4260bd6d968c940c9979583118a 8330108: Increase CipherInputStream buffer size Reviewed-by: ascarpino, shade ! src/java.base/share/classes/javax/crypto/CipherInputStream.java Changeset: 3d5eeac3 Author: Alexey Ivanov Date: 2024-04-23 12:57:24 +0000 URL: https://git.openjdk.org/leyden/commit/3d5eeac3a38ece4a23ea6da2dfe5939d64e81cea 8289770: Remove Windows version macro from ShellFolder2.cpp Reviewed-by: jwaters, tr, serb ! src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp Changeset: 2ea89268 Author: Albert Mingkun Yang Date: 2024-04-23 15:01:09 +0000 URL: https://git.openjdk.org/leyden/commit/2ea89268a1af501fef4c1505a487e9ef5d5bda87 8330961: Remove redundant public specifier in ModRefBarrierSet Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/modRefBarrierSet.hpp Changeset: 383fe6ea Author: Matias Saavedra Silva Date: 2024-04-23 15:02:27 +0000 URL: https://git.openjdk.org/leyden/commit/383fe6eaab423a1218c9915362f691472e3773e7 8330388: Remove invokedynamic cache index encoding Reviewed-by: cjplummer, dlong, coleenp ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/arm/interp_masm_arm.cpp ! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp ! src/hotspot/cpu/riscv/interp_masm_riscv.cpp ! src/hotspot/cpu/s390/interp_masm_s390.cpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/share/c1/c1_Runtime1.cpp ! src/hotspot/share/cds/classListParser.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/ci/ciStreams.cpp ! src/hotspot/share/classfile/resolutionErrors.hpp ! src/hotspot/share/interpreter/abstractInterpreter.cpp ! src/hotspot/share/interpreter/bootstrapInfo.cpp ! src/hotspot/share/interpreter/bootstrapInfo.hpp ! src/hotspot/share/interpreter/bytecode.cpp ! src/hotspot/share/interpreter/bytecodeTracer.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/rewriter.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/constantPool.hpp ! src/hotspot/share/oops/constantPool.inline.hpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp ! src/hotspot/share/prims/methodComparator.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithCPIndex.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/CompilerToVM.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotConstantPool.java ! test/hotspot/jtreg/compiler/jvmci/common/patches/jdk.internal.vm.ci/jdk/vm/ci/hotspot/CompilerToVMHelper.java ! test/hotspot/jtreg/compiler/jvmci/compilerToVM/ConstantPoolTestsHelper.java Changeset: b6518a5d Author: Matias Saavedra Silva Date: 2024-04-23 15:07:55 +0000 URL: https://git.openjdk.org/leyden/commit/b6518a5db08959a5d1a22ccff9c1795ce7f9bf85 8329417: Remove objects with no pointers from relocation bitmap Reviewed-by: ccheung, iklam ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveBuilder.hpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/cds/metaspaceShared.cpp Changeset: b07e1531 Author: Guoxiong Li Date: 2024-04-23 15:22:17 +0000 URL: https://git.openjdk.org/leyden/commit/b07e1531b375b9d8117e218355e70272e27e1225 8330362: G1: Inline offset array element accessor in G1BlockOffsetTable Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp Changeset: 412e306d Author: Alan Bateman Date: 2024-04-23 16:10:13 +0000 URL: https://git.openjdk.org/leyden/commit/412e306d81209c05f55aee7663f7abb80286e361 8329593: Drop adjustments to target parallelism when virtual threads do I/O on files opened for buffered I/O Reviewed-by: bpb, jpai ! src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java ! src/java.base/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java ! src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java ! src/java.base/share/classes/java/io/FileDescriptor.java ! src/java.base/share/classes/java/io/FileInputStream.java ! src/java.base/share/classes/java/io/FileOutputStream.java ! src/java.base/share/classes/java/io/RandomAccessFile.java ! src/java.base/share/classes/java/lang/Object.java ! src/java.base/share/classes/java/lang/Process.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/VirtualThread.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/nio/MappedMemoryUtils.java ! src/java.base/share/classes/jdk/internal/misc/Blocker.java ! src/java.base/share/classes/jdk/internal/misc/CarrierThread.java ! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java ! src/java.base/unix/classes/java/io/UnixFileSystem.java ! src/java.base/unix/classes/java/lang/ProcessImpl.java ! src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java ! src/java.base/unix/classes/sun/nio/fs/UnixChannelFactory.java ! src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java ! src/java.base/unix/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/java.base/windows/classes/java/io/WinNTFileSystem.java ! src/java.base/windows/classes/java/lang/ProcessImpl.java ! src/java.base/windows/classes/sun/nio/ch/WEPollSelectorImpl.java ! src/java.base/windows/classes/sun/nio/fs/WindowsChannelFactory.java ! src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java Changeset: b4cea701 Author: Guoxiong Li Date: 2024-04-23 16:32:20 +0000 URL: https://git.openjdk.org/leyden/commit/b4cea701c9cab15007c485088dd5b8d7025d83ef 8330693: Generational ZGC: Simplify ZAddress::finalizable_good and ZAddress::mark_good Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zAddress.inline.hpp Changeset: 7157eea1 Author: Sonia Zaldana Calles Committer: Coleen Phillimore Date: 2024-04-23 18:01:55 +0000 URL: https://git.openjdk.org/leyden/commit/7157eea10130e5411ab8db4273dc37f6789cdcf6 8327290: Remove unused notproduct option TraceInvocationCounterOverflow Reviewed-by: coleenp ! src/hotspot/share/runtime/globals.hpp Changeset: 88a5dcea Author: Aleksei Voitylov Committer: Aleksey Shipilev Date: 2024-04-23 18:12:10 +0000 URL: https://git.openjdk.org/leyden/commit/88a5dcead21f50e367f8ad77197e6ffdb98cbb20 8330805: ARM32 build is broken after JDK-8139457 Reviewed-by: shade ! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp Changeset: 9cc163a9 Author: Jonathan Gibbons Date: 2024-04-23 18:43:36 +0000 URL: https://git.openjdk.org/leyden/commit/9cc163a999eb8e9597d45b095b642c25071043bd 8330178: Clean up non-standard use of /** comments in `java.base` Reviewed-by: darcy, iris, dfuchs, aivanov, naoto ! src/java.base/macosx/classes/apple/security/AppleProvider.java ! src/java.base/macosx/classes/java/net/DefaultInterface.java ! src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java ! src/java.base/share/classes/java/io/FilePermission.java ! src/java.base/share/classes/java/io/ObjectStreamConstants.java ! src/java.base/share/classes/java/lang/invoke/LambdaForm.java ! src/java.base/share/classes/java/math/BigInteger.java ! src/java.base/share/classes/java/math/MutableBigInteger.java ! src/java.base/share/classes/java/net/HttpURLConnection.java ! src/java.base/share/classes/java/util/regex/Pattern.java ! src/java.base/share/classes/jdk/internal/access/JavaAWTFontAccess.java ! src/java.base/share/classes/jdk/internal/icu/lang/UCharacter.java ! src/java.base/share/classes/jdk/internal/icu/text/BidiBase.java ! src/java.base/share/classes/jdk/internal/icu/text/UTF16.java ! src/java.base/share/classes/jdk/internal/platform/Metrics.java ! src/java.base/share/classes/sun/net/www/content/text/plain.java ! src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java ! src/java.base/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java ! src/java.base/share/classes/sun/nio/ch/Interruptible.java ! src/java.base/share/classes/sun/security/pkcs/ParsingException.java ! src/java.base/share/classes/sun/security/provider/SeedGenerator.java ! src/java.base/share/classes/sun/security/util/ByteArrayTagOrder.java ! src/java.base/share/classes/sun/security/util/IOUtils.java Changeset: 09b88098 Author: Sonia Zaldana Calles Committer: Coleen Phillimore Date: 2024-04-23 19:06:41 +0000 URL: https://git.openjdk.org/leyden/commit/09b88098ff544fec1a4e94bfbbdc21b6c8433abb 8327289: Remove unused PrintMethodFlushingStatistics option Reviewed-by: coleenp ! src/hotspot/share/runtime/globals.hpp Changeset: 25551662 Author: Alex Menkov Date: 2024-04-23 20:37:25 +0000 URL: https://git.openjdk.org/leyden/commit/2555166247230497453503318ccbf4dd4f047193 8329113: Deprecate -XX:+UseNotificationThread Reviewed-by: dcubed, dholmes, coleenp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: f60798a3 Author: Justin Lu Date: 2024-04-23 21:10:46 +0000 URL: https://git.openjdk.org/leyden/commit/f60798a30e9a3e0b666fed5384b6ac92a8a283dd 8329222: java.text.NumberFormat (and subclasses) spec updates Reviewed-by: naoto ! src/java.base/share/classes/java/text/CompactNumberFormat.java ! src/java.base/share/classes/java/text/DecimalFormat.java ! src/java.base/share/classes/java/text/NumberFormat.java Changeset: 7a895552 Author: Scott Gibbons Committer: Sandhya Viswanathan Date: 2024-04-23 23:35:59 +0000 URL: https://git.openjdk.org/leyden/commit/7a895552c8eb9ae19f8d6eb8c35a0393445305fa 8330844: Add aliases for conditional jumps and additional instruction forms for x86 Reviewed-by: kvn, epeter, sviswanathan ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp Changeset: 80b381e9 Author: Jatin Bhateja Date: 2024-04-24 02:19:03 +0000 URL: https://git.openjdk.org/leyden/commit/80b381e91bb649e440321a440ce641a54f89dfb4 8329555: Crash in intrinsifying heap-based MemorySegment Vector store/loads Reviewed-by: sviswanathan, kvn ! src/hotspot/share/opto/vectorIntrinsics.cpp + test/hotspot/jtreg/compiler/vectorapi/TestBiMorphicMismatchedMemSegment.java Changeset: 438e6431 Author: Jasmine Karthikeyan Committer: Tobias Hartmann Date: 2024-04-24 05:22:51 +0000 URL: https://git.openjdk.org/leyden/commit/438e64310dc186d05de758103df1ea5504dcf33e 8329531: compiler/c2/irTests/TestIfMinMax.java fails with IRViolationException: There were one or multiple IR rule failures. Reviewed-by: epeter, dfenacci ! test/hotspot/jtreg/compiler/c2/irTests/TestIfMinMax.java Changeset: 5c383860 Author: Joshua Zhu Committer: Tobias Hartmann Date: 2024-04-24 05:44:39 +0000 URL: https://git.openjdk.org/leyden/commit/5c3838605d48d7f2db981c5e821c08d84856c53c 8326541: [AArch64] ZGC C2 load barrier stub should consider the length of live registers when spilling registers Reviewed-by: eosterlund, rcastanedalo ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/vmreg_aarch64.hpp + test/hotspot/jtreg/gc/z/TestRegistersPushPopAtZGCLoadBarrierStub.java Changeset: 3ccb64c0 Author: Emanuel Peter Date: 2024-04-24 06:44:14 +0000 URL: https://git.openjdk.org/leyden/commit/3ccb64c0216c72008578b904d0e7e5bba5e11134 8318446: C2: optimize stores into primitive arrays by combining values into larger store Reviewed-by: kvn, thartmann ! make/test/BuildMicrobenchmark.gmk ! src/hotspot/share/opto/addnode.cpp ! src/hotspot/share/opto/addnode.hpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/phaseX.cpp + test/hotspot/jtreg/compiler/c2/TestMergeStores.java + test/micro/org/openjdk/bench/vm/compiler/MergeStores.java Changeset: 165ba87e Author: Tobias Holenstein Date: 2024-04-24 07:24:39 +0000 URL: https://git.openjdk.org/leyden/commit/165ba87e5732c382b3e97315e959dd5e32cf2984 8330587: IGV: remove ControlFlowTopComponent Reviewed-by: chagedorn, rcastanedalo - src/utils/IdealGraphVisualizer/ControlFlow/pom.xml - src/utils/IdealGraphVisualizer/ControlFlow/src/main/java/com/sun/hotspot/igv/controlflow/BlockConnectionWidget.java - src/utils/IdealGraphVisualizer/ControlFlow/src/main/java/com/sun/hotspot/igv/controlflow/BlockWidget.java - src/utils/IdealGraphVisualizer/ControlFlow/src/main/java/com/sun/hotspot/igv/controlflow/ControlFlowAction.java - src/utils/IdealGraphVisualizer/ControlFlow/src/main/java/com/sun/hotspot/igv/controlflow/ControlFlowScene.java - src/utils/IdealGraphVisualizer/ControlFlow/src/main/java/com/sun/hotspot/igv/controlflow/ControlFlowTopComponent.form - src/utils/IdealGraphVisualizer/ControlFlow/src/main/java/com/sun/hotspot/igv/controlflow/ControlFlowTopComponent.java - src/utils/IdealGraphVisualizer/ControlFlow/src/main/java/com/sun/hotspot/igv/controlflow/DoubleClickSelectAction.java - src/utils/IdealGraphVisualizer/ControlFlow/src/main/java/com/sun/hotspot/igv/controlflow/HierarchicalGraphLayout.java - src/utils/IdealGraphVisualizer/ControlFlow/src/main/nbm/manifest.mf - src/utils/IdealGraphVisualizer/ControlFlow/src/main/resources/com/sun/hotspot/igv/controlflow/Bundle.properties - src/utils/IdealGraphVisualizer/ControlFlow/src/main/resources/com/sun/hotspot/igv/controlflow/ControlFlowTopComponentSettings.xml - src/utils/IdealGraphVisualizer/ControlFlow/src/main/resources/com/sun/hotspot/igv/controlflow/ControlFlowTopComponentWstcref.xml - src/utils/IdealGraphVisualizer/ControlFlow/src/main/resources/com/sun/hotspot/igv/controlflow/layer.xml ! src/utils/IdealGraphVisualizer/application/pom.xml ! src/utils/IdealGraphVisualizer/pom.xml Changeset: c439c8c7 Author: Galder Zamarre?o Committer: Andrew Dinn Date: 2024-04-24 08:20:49 +0000 URL: https://git.openjdk.org/leyden/commit/c439c8c73cf07966e3517ecbaf14d79dcbaeabb3 8323429: Missing C2 optimization for FP min/max when both inputs are same Reviewed-by: roland, chagedorn ! src/hotspot/share/opto/addnode.cpp ! src/hotspot/share/opto/addnode.hpp + test/hotspot/jtreg/compiler/intrinsics/math/TestMinMaxOpt.java ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicDoubleOpTest.java Changeset: e681e9b4 Author: Emanuel Peter Date: 2024-04-24 08:45:32 +0000 URL: https://git.openjdk.org/leyden/commit/e681e9b4d78c57d031e08e11dfa6250d1f52f5f5 8330819: C2 SuperWord: bad dominance after pre-loop limit adjustment with base that has CastLL after pre-loop Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/vectorization.cpp + test/hotspot/jtreg/compiler/loopopts/superword/TestMemorySegmentMainLoopAlignment.java Changeset: 174d6265 Author: Serguei Spitsyn Date: 2024-04-24 09:02:02 +0000 URL: https://git.openjdk.org/leyden/commit/174d62652c69e811cf44ab64db575b13a848a728 8328741: serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with unexpected owner Reviewed-by: lmesnik, cjplummer ! test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java ! test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/libObjectMonitorUsage.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResumeAll/libSuspendResumeAll.cpp ! test/lib/jdk/test/lib/jvmti/jvmti_common.hpp Changeset: 7bb59dc8 Author: Albert Mingkun Yang Date: 2024-04-24 09:44:26 +0000 URL: https://git.openjdk.org/leyden/commit/7bb59dc8da0c61c5da5c3aab5d56a6e4880001ce 8330670: Obsolete ScavengeBeforeFullGC Reviewed-by: stefank, tschatzl ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/shared/gcArguments.cpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/gc/z/zDriver.cpp ! src/hotspot/share/runtime/arguments.cpp ! test/hotspot/jtreg/vmTestbase/gc/gctests/WeakReference/weak006/weak006.java Changeset: 2bb5cf5f Author: Guoxiong Li Date: 2024-04-24 11:41:21 +0000 URL: https://git.openjdk.org/leyden/commit/2bb5cf5f33337b2cc40aca3bdd36400dc4af5723 8330155: Serial: Remove TenuredSpace Reviewed-by: ayang, cjplummer, tschatzl ! src/hotspot/share/gc/g1/g1CollectionSetChooser.cpp ! src/hotspot/share/gc/serial/cardTableRS.cpp ! src/hotspot/share/gc/serial/cardTableRS.hpp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/generation.cpp ! src/hotspot/share/gc/serial/generation.hpp ! src/hotspot/share/gc/serial/serialFullGC.cpp ! src/hotspot/share/gc/serial/serialHeap.inline.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.inline.hpp ! src/hotspot/share/gc/serial/vmStructs_serial.hpp ! src/hotspot/share/gc/shared/cardTable.cpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.cpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/space.hpp - src/hotspot/share/gc/shared/space.inline.hpp ! src/hotspot/share/gc/shared/spaceDecorator.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/TenuredSpace.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbField.java Changeset: 15190816 Author: Serguei Spitsyn Date: 2024-04-24 11:43:49 +0000 URL: https://git.openjdk.org/leyden/commit/15190816f704f2e8681bc3e2d74832828a574106 8330303: Crash: assert(_target_jt == nullptr || _target_jt->vthread() == target_h()) failed Reviewed-by: pchilanomate, cjplummer, lmesnik ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiEnvBase.hpp ! src/hotspot/share/prims/jvmtiEnvThreadState.cpp Changeset: e923dfe4 Author: Per Minborg Date: 2024-04-24 11:56:44 +0000 URL: https://git.openjdk.org/leyden/commit/e923dfe4c51291099d9b7411e6c9f20be79b9a53 8314592: Add shortcut to SymbolLookup::find Reviewed-by: jvernee, prr ! src/java.base/share/classes/java/lang/foreign/Linker.java ! src/java.base/share/classes/java/lang/foreign/SymbolLookup.java ! src/java.base/share/classes/java/lang/foreign/package-info.java ! src/java.base/share/classes/java/lang/foreign/snippet-files/Snippets.java ! src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java ! src/java.desktop/share/classes/sun/font/HBShaper.java ! test/hotspot/jtreg/gc/shenandoah/compiler/TestLinkToNativeRBP.java + test/jdk/java/foreign/loaderLookup/TestSymbolLookupFindOrThrow.java ! test/micro/org/openjdk/bench/java/lang/foreign/AllocTest.java ! test/micro/org/openjdk/bench/java/lang/foreign/CLayouts.java ! test/micro/org/openjdk/bench/java/lang/foreign/CallOverheadHelper.java ! test/micro/org/openjdk/bench/java/lang/foreign/CriticalCalls.java ! test/micro/org/openjdk/bench/java/lang/foreign/PointerInvoke.java ! test/micro/org/openjdk/bench/java/lang/foreign/QSort.java ! test/micro/org/openjdk/bench/java/lang/foreign/StrLenTest.java ! test/micro/org/openjdk/bench/java/lang/foreign/ToCStringTest.java ! test/micro/org/openjdk/bench/java/lang/foreign/Upcalls.java ! test/micro/org/openjdk/bench/java/lang/foreign/points/support/PanamaPoint.java ! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayForeignXorOpCriticalImpl.java ! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayForeignXorOpImpl.java ! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayForeignXorOpInitImpl.java ! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayUnsafeXorOpImpl.java Changeset: e311ba32 Author: Stefan Johansson Date: 2024-04-24 12:03:30 +0000 URL: https://git.openjdk.org/leyden/commit/e311ba32a517a6389c683c3597d78f66fe52991e 8330626: ZGC: Windows address space placeholders not managed correctly Reviewed-by: stefank, aboldtch ! src/hotspot/os/windows/gc/z/zVirtualMemory_windows.cpp ! src/hotspot/share/gc/z/zVirtualMemory.hpp + test/hotspot/gtest/gc/z/test_zMapper_windows.cpp Changeset: 45ed97f1 Author: Matthias Baesken Date: 2024-04-24 12:55:34 +0000 URL: https://git.openjdk.org/leyden/commit/45ed97f15b96071e5d6b6d21e8f0129eda5aa447 8330464: hserr generic events - add entry for the before_exit calls Reviewed-by: rrich, lucy ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/threads.cpp Changeset: 74b11ccf Author: Albert Mingkun Yang Date: 2024-04-24 13:34:35 +0000 URL: https://git.openjdk.org/leyden/commit/74b11ccf143b335c0e3f21e9fe5dc024742b1bc4 8331004: Serial: Remove unused GenClosure Reviewed-by: gli, tschatzl ! src/hotspot/share/gc/serial/serialHeap.hpp Changeset: f1d0e715 Author: Gerard Ziemski Date: 2024-04-24 14:27:10 +0000 URL: https://git.openjdk.org/leyden/commit/f1d0e715b67e2ca47b525069d8153abbb33f75b9 8324577: [REDO] - [IMPROVE] OPEN_MAX is no longer the max limit on macOS >= 10.6 for RLIMIT_NOFILE Reviewed-by: dcubed, dholmes ! src/hotspot/os/bsd/os_bsd.cpp Changeset: 1d061707 Author: Joshua Cao Committer: Aleksey Shipilev Date: 2024-04-24 17:06:45 +0000 URL: https://git.openjdk.org/leyden/commit/1d06170758bd76a0ea32e5bb7d4a017e829ae710 8300148: Consider using a StoreStore barrier instead of Release barrier on ctor exit Reviewed-by: shade, kvn, dlong ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/opto/stringopts.cpp + test/hotspot/jtreg/compiler/c2/irTests/ConstructorBarriers.java ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java + test/micro/org/openjdk/bench/vm/compiler/ConstructorBarriers.java Changeset: 25871af3 Author: Phil Race Date: 2024-04-24 17:54:10 +0000 URL: https://git.openjdk.org/leyden/commit/25871af36b1397bdc3715ab0edc589f0483ea0b1 8328896: Fontmetrics for large Fonts has zero width Reviewed-by: tr, serb ! src/java.desktop/macosx/classes/sun/font/CStrike.java ! src/java.desktop/macosx/native/libawt_lwawt/font/CGGlyphImages.m ! src/java.desktop/share/classes/sun/font/FileFontStrike.java ! src/java.desktop/share/native/libfontmanager/freetypeScaler.c + test/jdk/java/awt/FontMetrics/ExtremeFontSizeTest.java Changeset: 7b2560b4 Author: Roman Kennke Date: 2024-04-24 18:56:47 +0000 URL: https://git.openjdk.org/leyden/commit/7b2560b4904d80629d3f4f25c65d9b96eee9bdb6 8330849: Add test to verify memory usage with recursive locking Reviewed-by: lmesnik, shade + test/hotspot/jtreg/runtime/locking/TestRecursiveMonitorChurn.java Changeset: ea3909ac Author: Emanuel Peter Date: 2024-04-24 19:06:46 +0000 URL: https://git.openjdk.org/leyden/commit/ea3909acd117cab97c6c0b496f98f9a4a3a22be4 8331054: C2 MergeStores: assert failed: unexpected basic type after JDK-8318446 and JDK-8329555 Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/memnode.cpp ! test/hotspot/jtreg/compiler/c2/TestMergeStores.java Changeset: 0014e0e6 Author: Albert Mingkun Yang Date: 2024-04-24 19:56:20 +0000 URL: https://git.openjdk.org/leyden/commit/0014e0e6b90502ed284a57ce2d1ff48843cbc0fa 8331061: Serial: Missed BOT update in TenuredGeneration::expand_and_allocate Reviewed-by: tschatzl, gli ! src/hotspot/share/gc/serial/tenuredGeneration.cpp Changeset: 8a8d9288 Author: Martin Balao Date: 2024-04-24 20:23:25 +0000 URL: https://git.openjdk.org/leyden/commit/8a8d9288980513db459f7d6b36554b65844951ca 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, AVX-512) Co-authored-by: Francisco Ferrari Bihurriet Co-authored-by: Martin Balao Reviewed-by: aph, sviswanathan ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp Changeset: a44ac026 Author: Vladimir Kozlov Date: 2024-04-24 20:42:50 +0000 URL: https://git.openjdk.org/leyden/commit/a44ac026c599df629305588e09fbbcff9be2a5c0 8330853: Add missing checks for ConnectionGraph::can_reduce_cmp() call Reviewed-by: iveresov, dlong, cslucas ! src/hotspot/share/opto/escape.cpp Changeset: e6118ce7 Author: Jonathan Gibbons Date: 2024-04-24 20:45:23 +0000 URL: https://git.openjdk.org/leyden/commit/e6118ce784342e1f1996f1569cf636a6b435145d 8331018: Clean up non-standard use of /** comments in `jdk.jshell` Reviewed-by: iris, darcy, jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/DeclarationSnippet.java ! src/jdk.jshell/share/classes/jdk/jshell/ExpressionSnippet.java ! src/jdk.jshell/share/classes/jdk/jshell/ImportSnippet.java ! src/jdk.jshell/share/classes/jdk/jshell/MaskCommentsAndModifiers.java ! src/jdk.jshell/share/classes/jdk/jshell/MethodSnippet.java ! src/jdk.jshell/share/classes/jdk/jshell/Snippet.java ! src/jdk.jshell/share/classes/jdk/jshell/TypeDeclSnippet.java Changeset: 21480a7a Author: Tejesh R Date: 2024-04-25 04:31:55 +0000 URL: https://git.openjdk.org/leyden/commit/21480a7ae8dce67cf3a844d8caafb0b96c37ac0e 8322135: Printing JTable in Windows L&F throws InternalError: HTHEME is null Reviewed-by: abhiscxk, honkar, aivanov ! src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java ! test/jdk/javax/swing/JTable/JTableScrollPrintTest.java ! test/jdk/javax/swing/JTable/PrintAllPagesTest.java Changeset: d43654e5 Author: Christian Stein Date: 2024-04-25 06:49:45 +0000 URL: https://git.openjdk.org/leyden/commit/d43654e5733a4ad535e95d908de528ef29285e92 8331030: langtools/tools/javac/tree tests fail with SOE with fastdebug and -Xcomp Reviewed-by: jjg, vromero ! test/langtools/tools/javac/patterns/SOEDeeplyNestedBlocksTest.java Changeset: e818ab60 Author: Christoph Langer Date: 2024-04-25 06:53:36 +0000 URL: https://git.openjdk.org/leyden/commit/e818ab60a0c1dac277b8b15301cdfb7d439ed26c 8330815: Use pattern matching for instanceof in KeepAliveCache Reviewed-by: jpai, djelinski ! src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java Changeset: ccc0d0f7 Author: Adam Sotona Date: 2024-04-25 07:04:39 +0000 URL: https://git.openjdk.org/leyden/commit/ccc0d0f7b194a9941e2cadba1c389aa0834c52e4 8325373: Improve StackCounter error reporting for bad switch cases Reviewed-by: psandoz ! src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java ! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java ! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java Changeset: d32f1092 Author: Joshua Cao Committer: Tobias Hartmann Date: 2024-04-25 07:11:12 +0000 URL: https://git.openjdk.org/leyden/commit/d32f10921985031505718ec29fb97a36f9ba24c0 8329797: Shenandoah: Default case invoked for: "MaxL" (bad AD file) Reviewed-by: shade, thartmann ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/movenode.cpp ! test/hotspot/jtreg/compiler/c2/irTests/TestIfMinMax.java Changeset: ef745a6c Author: Adam Sotona Date: 2024-04-25 08:09:52 +0000 URL: https://git.openjdk.org/leyden/commit/ef745a6c6e4068e786a70fc5574d272140c01e0f 8331097: Tests build is broken after pr/18914 Reviewed-by: alanb ! test/micro/org/openjdk/bench/jdk/classfile/CodeAttributeTools.java Changeset: 87e864bf Author: Jan Lahoda Date: 2024-04-25 08:11:56 +0000 URL: https://git.openjdk.org/leyden/commit/87e864bf21d71daae4e001ec4edbb4ef1f60c36d 8328703: Illegal accesses in Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_ioctl0 Reviewed-by: asotona, shade ! src/jdk.internal.le/linux/native/lible/CLibrary.cpp ! src/jdk.internal.le/macosx/native/lible/CLibrary.cpp Changeset: b1b953c4 Author: Guoxiong Li Date: 2024-04-25 08:56:18 +0000 URL: https://git.openjdk.org/leyden/commit/b1b953c427b9562f050760ab3c2d0ae09aeec3e5 8330972: Serial: Inline Generation::max_contiguous_available Reviewed-by: ayang ! src/hotspot/share/gc/serial/generation.cpp ! src/hotspot/share/gc/serial/generation.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp Changeset: c9f8d0ef Author: Albert Mingkun Yang Date: 2024-04-25 09:49:10 +0000 URL: https://git.openjdk.org/leyden/commit/c9f8d0eff706d9ac59179afbb821367da09c9aae 8331050: Serial: Remove unused _saved_mark_word in DefNewGeneration and TenuredGeneration Reviewed-by: gli, tschatzl ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp Changeset: 8031dabf Author: Stefan Johansson Date: 2024-04-25 10:43:07 +0000 URL: https://git.openjdk.org/leyden/commit/8031dabf8344108a1c225311f2f270764fb2bc00 8331094: ZGC: GTest fails due to incompatible Windows version Reviewed-by: aboldtch, tschatzl ! test/hotspot/gtest/gc/z/test_zMapper_windows.cpp Changeset: c9442014 Author: Matthias Baesken Date: 2024-04-25 12:02:31 +0000 URL: https://git.openjdk.org/leyden/commit/c9442014e561f8e1cb43a0e9f18a9a5ae2a7a2da 8331031: unify os::dont_yield and os::naked_yield across Posix platforms Reviewed-by: coleenp, mdoerr ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/posix/os_posix.cpp Changeset: b9927aa3 Author: Jasmine Karthikeyan Committer: Tobias Hartmann Date: 2024-04-25 13:13:25 +0000 URL: https://git.openjdk.org/leyden/commit/b9927aa3a4c77812bfc53b14a6695ec436737661 8329194: Cleanup Type::cmp definition and usage Reviewed-by: dfenacci, chagedorn, qamai ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/type.hpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp Changeset: 4dfaa9b5 Author: Roger Riggs Date: 2024-04-25 14:37:38 +0000 URL: https://git.openjdk.org/leyden/commit/4dfaa9b5bd4f9733e5a67d7c5b55eaa5ad4e27e4 8329805: Deprecate for removal ObjectOutputStream.PutField.write Reviewed-by: naoto, iris ! src/java.base/share/classes/java/io/ObjectOutputStream.java Changeset: 5af6b45e Author: Matthias Baesken Date: 2024-04-25 15:23:48 +0000 URL: https://git.openjdk.org/leyden/commit/5af6b45eefd227e3e046ca22a404ae8a23174160 8330615: avoid signed integer overflows in zip_util.c readCen / hashN Reviewed-by: lucy, mdoerr ! src/java.base/share/native/libzip/zip_util.c Changeset: ce9eac38 Author: SendaoYan Committer: Magnus Ihse Bursie Date: 2024-04-25 15:54:13 +0000 URL: https://git.openjdk.org/leyden/commit/ce9eac38191fa700afa3ac06b2b202576a11dd71 8331113: createJMHBundle.sh support configurable maven repo mirror Reviewed-by: redestad, erikj ! make/devkit/createJMHBundle.sh Changeset: 1c238d43 Author: Naoto Sato Date: 2024-04-25 16:19:51 +0000 URL: https://git.openjdk.org/leyden/commit/1c238d43e81acf516297f26660059d0bab5b5b8a 8319990: Update CLDR to Version 45.0 Reviewed-by: joehw, jlu = make/data/cldr/LICENSE - make/data/cldr/README + make/data/cldr/README-common.md ! make/data/cldr/common/bcp47/collation.xml ! make/data/cldr/common/bcp47/currency.xml ! make/data/cldr/common/dtd/ldml.dtd ! make/data/cldr/common/dtd/ldml.xsd ! make/data/cldr/common/dtd/ldmlBCP47.dtd ! make/data/cldr/common/dtd/ldmlBCP47.xsd ! make/data/cldr/common/dtd/ldmlICU.dtd ! make/data/cldr/common/dtd/ldmlSupplemental.dtd ! make/data/cldr/common/dtd/ldmlSupplemental.xsd ! make/data/cldr/common/main/aa.xml ! make/data/cldr/common/main/aa_DJ.xml ! make/data/cldr/common/main/aa_ER.xml ! make/data/cldr/common/main/aa_ET.xml ! make/data/cldr/common/main/ab.xml ! make/data/cldr/common/main/ab_GE.xml ! make/data/cldr/common/main/af.xml ! make/data/cldr/common/main/af_NA.xml ! make/data/cldr/common/main/af_ZA.xml ! make/data/cldr/common/main/agq.xml ! make/data/cldr/common/main/agq_CM.xml ! make/data/cldr/common/main/ak.xml ! make/data/cldr/common/main/ak_GH.xml ! make/data/cldr/common/main/am.xml ! make/data/cldr/common/main/am_ET.xml ! make/data/cldr/common/main/an.xml ! make/data/cldr/common/main/an_ES.xml ! make/data/cldr/common/main/ann.xml ! make/data/cldr/common/main/ann_NG.xml ! make/data/cldr/common/main/apc.xml ! make/data/cldr/common/main/apc_SY.xml ! make/data/cldr/common/main/ar.xml ! make/data/cldr/common/main/ar_001.xml ! make/data/cldr/common/main/ar_AE.xml ! make/data/cldr/common/main/ar_BH.xml ! make/data/cldr/common/main/ar_DJ.xml ! make/data/cldr/common/main/ar_DZ.xml ! make/data/cldr/common/main/ar_EG.xml ! make/data/cldr/common/main/ar_EH.xml ! make/data/cldr/common/main/ar_ER.xml ! make/data/cldr/common/main/ar_IL.xml ! make/data/cldr/common/main/ar_IQ.xml ! make/data/cldr/common/main/ar_JO.xml ! make/data/cldr/common/main/ar_KM.xml ! make/data/cldr/common/main/ar_KW.xml ! make/data/cldr/common/main/ar_LB.xml ! make/data/cldr/common/main/ar_LY.xml ! make/data/cldr/common/main/ar_MA.xml ! make/data/cldr/common/main/ar_MR.xml ! make/data/cldr/common/main/ar_OM.xml ! make/data/cldr/common/main/ar_PS.xml ! make/data/cldr/common/main/ar_QA.xml ! make/data/cldr/common/main/ar_SA.xml ! make/data/cldr/common/main/ar_SD.xml ! make/data/cldr/common/main/ar_SO.xml ! make/data/cldr/common/main/ar_SS.xml ! make/data/cldr/common/main/ar_SY.xml ! make/data/cldr/common/main/ar_TD.xml ! make/data/cldr/common/main/ar_TN.xml ! make/data/cldr/common/main/ar_YE.xml ! make/data/cldr/common/main/arn.xml ! make/data/cldr/common/main/arn_CL.xml ! make/data/cldr/common/main/as.xml ! make/data/cldr/common/main/as_IN.xml ! make/data/cldr/common/main/asa.xml ! make/data/cldr/common/main/asa_TZ.xml ! make/data/cldr/common/main/ast.xml ! make/data/cldr/common/main/ast_ES.xml ! make/data/cldr/common/main/az.xml ! make/data/cldr/common/main/az_Arab.xml ! make/data/cldr/common/main/az_Arab_IQ.xml ! make/data/cldr/common/main/az_Arab_IR.xml ! make/data/cldr/common/main/az_Arab_TR.xml ! make/data/cldr/common/main/az_Cyrl.xml ! make/data/cldr/common/main/az_Cyrl_AZ.xml ! make/data/cldr/common/main/az_Latn.xml ! make/data/cldr/common/main/az_Latn_AZ.xml ! make/data/cldr/common/main/ba.xml ! make/data/cldr/common/main/ba_RU.xml ! make/data/cldr/common/main/bal.xml ! make/data/cldr/common/main/bal_Arab.xml ! make/data/cldr/common/main/bal_Arab_PK.xml ! make/data/cldr/common/main/bal_Latn.xml ! make/data/cldr/common/main/bal_Latn_PK.xml ! make/data/cldr/common/main/bas.xml ! make/data/cldr/common/main/bas_CM.xml ! make/data/cldr/common/main/be.xml ! make/data/cldr/common/main/be_BY.xml ! make/data/cldr/common/main/be_TARASK.xml ! make/data/cldr/common/main/bem.xml ! make/data/cldr/common/main/bem_ZM.xml ! make/data/cldr/common/main/bew.xml ! make/data/cldr/common/main/bew_ID.xml ! make/data/cldr/common/main/bez.xml ! make/data/cldr/common/main/bez_TZ.xml ! make/data/cldr/common/main/bg.xml ! make/data/cldr/common/main/bg_BG.xml ! make/data/cldr/common/main/bgc.xml ! make/data/cldr/common/main/bgc_IN.xml ! make/data/cldr/common/main/bgn.xml ! make/data/cldr/common/main/bgn_AE.xml ! make/data/cldr/common/main/bgn_AF.xml ! make/data/cldr/common/main/bgn_IR.xml ! make/data/cldr/common/main/bgn_OM.xml ! make/data/cldr/common/main/bgn_PK.xml ! make/data/cldr/common/main/bho.xml ! make/data/cldr/common/main/bho_IN.xml ! make/data/cldr/common/main/blo.xml ! make/data/cldr/common/main/blo_BJ.xml ! make/data/cldr/common/main/blt.xml ! make/data/cldr/common/main/blt_VN.xml ! make/data/cldr/common/main/bm.xml ! make/data/cldr/common/main/bm_ML.xml ! make/data/cldr/common/main/bm_Nkoo.xml ! make/data/cldr/common/main/bm_Nkoo_ML.xml ! make/data/cldr/common/main/bn.xml ! make/data/cldr/common/main/bn_BD.xml ! make/data/cldr/common/main/bn_IN.xml ! make/data/cldr/common/main/bo.xml ! make/data/cldr/common/main/bo_CN.xml ! make/data/cldr/common/main/bo_IN.xml ! make/data/cldr/common/main/br.xml ! make/data/cldr/common/main/br_FR.xml ! make/data/cldr/common/main/brx.xml ! make/data/cldr/common/main/brx_IN.xml ! make/data/cldr/common/main/bs.xml ! make/data/cldr/common/main/bs_Cyrl.xml ! make/data/cldr/common/main/bs_Cyrl_BA.xml ! make/data/cldr/common/main/bs_Latn.xml ! make/data/cldr/common/main/bs_Latn_BA.xml ! make/data/cldr/common/main/bss.xml ! make/data/cldr/common/main/bss_CM.xml ! make/data/cldr/common/main/byn.xml ! make/data/cldr/common/main/byn_ER.xml ! make/data/cldr/common/main/ca.xml ! make/data/cldr/common/main/ca_AD.xml ! make/data/cldr/common/main/ca_ES.xml ! make/data/cldr/common/main/ca_ES_VALENCIA.xml ! make/data/cldr/common/main/ca_FR.xml ! make/data/cldr/common/main/ca_IT.xml ! make/data/cldr/common/main/cad.xml ! make/data/cldr/common/main/cad_US.xml ! make/data/cldr/common/main/cch.xml ! make/data/cldr/common/main/cch_NG.xml ! make/data/cldr/common/main/ccp.xml ! make/data/cldr/common/main/ccp_BD.xml ! make/data/cldr/common/main/ccp_IN.xml ! make/data/cldr/common/main/ce.xml ! make/data/cldr/common/main/ce_RU.xml ! make/data/cldr/common/main/ceb.xml ! make/data/cldr/common/main/ceb_PH.xml ! make/data/cldr/common/main/cgg.xml ! make/data/cldr/common/main/cgg_UG.xml ! make/data/cldr/common/main/cho.xml ! make/data/cldr/common/main/cho_US.xml ! make/data/cldr/common/main/chr.xml ! make/data/cldr/common/main/chr_US.xml ! make/data/cldr/common/main/cic.xml ! make/data/cldr/common/main/cic_US.xml ! make/data/cldr/common/main/ckb.xml ! make/data/cldr/common/main/ckb_IQ.xml ! make/data/cldr/common/main/ckb_IR.xml ! make/data/cldr/common/main/co.xml ! make/data/cldr/common/main/co_FR.xml ! make/data/cldr/common/main/cs.xml ! make/data/cldr/common/main/cs_CZ.xml ! make/data/cldr/common/main/csw.xml ! make/data/cldr/common/main/csw_CA.xml ! make/data/cldr/common/main/cu.xml ! make/data/cldr/common/main/cu_RU.xml ! make/data/cldr/common/main/cv.xml ! make/data/cldr/common/main/cv_RU.xml ! make/data/cldr/common/main/cy.xml ! make/data/cldr/common/main/cy_GB.xml ! make/data/cldr/common/main/da.xml ! make/data/cldr/common/main/da_DK.xml ! make/data/cldr/common/main/da_GL.xml ! make/data/cldr/common/main/dav.xml ! make/data/cldr/common/main/dav_KE.xml ! make/data/cldr/common/main/de.xml ! make/data/cldr/common/main/de_AT.xml ! make/data/cldr/common/main/de_BE.xml ! make/data/cldr/common/main/de_CH.xml ! make/data/cldr/common/main/de_DE.xml ! make/data/cldr/common/main/de_IT.xml ! make/data/cldr/common/main/de_LI.xml ! make/data/cldr/common/main/de_LU.xml ! make/data/cldr/common/main/dje.xml ! make/data/cldr/common/main/dje_NE.xml ! make/data/cldr/common/main/doi.xml ! make/data/cldr/common/main/doi_IN.xml ! make/data/cldr/common/main/dsb.xml ! make/data/cldr/common/main/dsb_DE.xml ! make/data/cldr/common/main/dua.xml ! make/data/cldr/common/main/dua_CM.xml ! make/data/cldr/common/main/dv.xml ! make/data/cldr/common/main/dv_MV.xml ! make/data/cldr/common/main/dyo.xml ! make/data/cldr/common/main/dyo_SN.xml ! make/data/cldr/common/main/dz.xml ! make/data/cldr/common/main/dz_BT.xml ! make/data/cldr/common/main/ebu.xml ! make/data/cldr/common/main/ebu_KE.xml ! make/data/cldr/common/main/ee.xml ! make/data/cldr/common/main/ee_GH.xml ! make/data/cldr/common/main/ee_TG.xml ! make/data/cldr/common/main/el.xml ! make/data/cldr/common/main/el_CY.xml ! make/data/cldr/common/main/el_GR.xml ! make/data/cldr/common/main/el_POLYTON.xml ! make/data/cldr/common/main/en.xml ! make/data/cldr/common/main/en_001.xml ! make/data/cldr/common/main/en_150.xml ! make/data/cldr/common/main/en_AE.xml ! make/data/cldr/common/main/en_AG.xml ! make/data/cldr/common/main/en_AI.xml ! make/data/cldr/common/main/en_AS.xml ! make/data/cldr/common/main/en_AT.xml ! make/data/cldr/common/main/en_AU.xml ! make/data/cldr/common/main/en_BB.xml ! make/data/cldr/common/main/en_BE.xml ! make/data/cldr/common/main/en_BI.xml ! make/data/cldr/common/main/en_BM.xml ! make/data/cldr/common/main/en_BS.xml ! make/data/cldr/common/main/en_BW.xml ! make/data/cldr/common/main/en_BZ.xml ! make/data/cldr/common/main/en_CA.xml ! make/data/cldr/common/main/en_CC.xml ! make/data/cldr/common/main/en_CH.xml ! make/data/cldr/common/main/en_CK.xml ! make/data/cldr/common/main/en_CM.xml ! make/data/cldr/common/main/en_CX.xml ! make/data/cldr/common/main/en_CY.xml ! make/data/cldr/common/main/en_DE.xml ! make/data/cldr/common/main/en_DG.xml ! make/data/cldr/common/main/en_DK.xml ! make/data/cldr/common/main/en_DM.xml ! make/data/cldr/common/main/en_Dsrt.xml ! make/data/cldr/common/main/en_Dsrt_US.xml ! make/data/cldr/common/main/en_ER.xml ! make/data/cldr/common/main/en_FI.xml ! make/data/cldr/common/main/en_FJ.xml ! make/data/cldr/common/main/en_FK.xml ! make/data/cldr/common/main/en_FM.xml ! make/data/cldr/common/main/en_GB.xml ! make/data/cldr/common/main/en_GD.xml ! make/data/cldr/common/main/en_GG.xml ! make/data/cldr/common/main/en_GH.xml ! make/data/cldr/common/main/en_GI.xml ! make/data/cldr/common/main/en_GM.xml ! make/data/cldr/common/main/en_GU.xml ! make/data/cldr/common/main/en_GY.xml ! make/data/cldr/common/main/en_HK.xml ! make/data/cldr/common/main/en_ID.xml ! make/data/cldr/common/main/en_IE.xml ! make/data/cldr/common/main/en_IL.xml ! make/data/cldr/common/main/en_IM.xml ! make/data/cldr/common/main/en_IN.xml ! make/data/cldr/common/main/en_IO.xml ! make/data/cldr/common/main/en_JE.xml ! make/data/cldr/common/main/en_JM.xml ! make/data/cldr/common/main/en_KE.xml ! make/data/cldr/common/main/en_KI.xml ! make/data/cldr/common/main/en_KN.xml ! make/data/cldr/common/main/en_KY.xml ! make/data/cldr/common/main/en_LC.xml ! make/data/cldr/common/main/en_LR.xml ! make/data/cldr/common/main/en_LS.xml ! make/data/cldr/common/main/en_MG.xml ! make/data/cldr/common/main/en_MH.xml ! make/data/cldr/common/main/en_MO.xml ! make/data/cldr/common/main/en_MP.xml ! make/data/cldr/common/main/en_MS.xml ! make/data/cldr/common/main/en_MT.xml ! make/data/cldr/common/main/en_MU.xml ! make/data/cldr/common/main/en_MV.xml ! make/data/cldr/common/main/en_MW.xml ! make/data/cldr/common/main/en_MY.xml ! make/data/cldr/common/main/en_NA.xml ! make/data/cldr/common/main/en_NF.xml ! make/data/cldr/common/main/en_NG.xml ! make/data/cldr/common/main/en_NL.xml ! make/data/cldr/common/main/en_NR.xml ! make/data/cldr/common/main/en_NU.xml ! make/data/cldr/common/main/en_NZ.xml ! make/data/cldr/common/main/en_PG.xml ! make/data/cldr/common/main/en_PH.xml ! make/data/cldr/common/main/en_PK.xml ! make/data/cldr/common/main/en_PN.xml ! make/data/cldr/common/main/en_PR.xml ! make/data/cldr/common/main/en_PW.xml ! make/data/cldr/common/main/en_RW.xml ! make/data/cldr/common/main/en_SB.xml ! make/data/cldr/common/main/en_SC.xml ! make/data/cldr/common/main/en_SD.xml ! make/data/cldr/common/main/en_SE.xml ! make/data/cldr/common/main/en_SG.xml ! make/data/cldr/common/main/en_SH.xml ! make/data/cldr/common/main/en_SI.xml ! make/data/cldr/common/main/en_SL.xml ! make/data/cldr/common/main/en_SS.xml ! make/data/cldr/common/main/en_SX.xml ! make/data/cldr/common/main/en_SZ.xml ! make/data/cldr/common/main/en_Shaw.xml ! make/data/cldr/common/main/en_Shaw_GB.xml ! make/data/cldr/common/main/en_TC.xml ! make/data/cldr/common/main/en_TK.xml ! make/data/cldr/common/main/en_TO.xml ! make/data/cldr/common/main/en_TT.xml ! make/data/cldr/common/main/en_TV.xml ! make/data/cldr/common/main/en_TZ.xml ! make/data/cldr/common/main/en_UG.xml ! make/data/cldr/common/main/en_UM.xml ! make/data/cldr/common/main/en_US.xml ! make/data/cldr/common/main/en_US_POSIX.xml ! make/data/cldr/common/main/en_VC.xml ! make/data/cldr/common/main/en_VG.xml ! make/data/cldr/common/main/en_VI.xml ! make/data/cldr/common/main/en_VU.xml ! make/data/cldr/common/main/en_WS.xml ! make/data/cldr/common/main/en_ZA.xml ! make/data/cldr/common/main/en_ZM.xml ! make/data/cldr/common/main/en_ZW.xml ! make/data/cldr/common/main/eo.xml ! make/data/cldr/common/main/eo_001.xml ! make/data/cldr/common/main/es.xml ! make/data/cldr/common/main/es_419.xml ! make/data/cldr/common/main/es_AR.xml ! make/data/cldr/common/main/es_BO.xml ! make/data/cldr/common/main/es_BR.xml ! make/data/cldr/common/main/es_BZ.xml ! make/data/cldr/common/main/es_CL.xml ! make/data/cldr/common/main/es_CO.xml ! make/data/cldr/common/main/es_CR.xml ! make/data/cldr/common/main/es_CU.xml ! make/data/cldr/common/main/es_DO.xml ! make/data/cldr/common/main/es_EA.xml ! make/data/cldr/common/main/es_EC.xml ! make/data/cldr/common/main/es_ES.xml ! make/data/cldr/common/main/es_GQ.xml ! make/data/cldr/common/main/es_GT.xml ! make/data/cldr/common/main/es_HN.xml ! make/data/cldr/common/main/es_IC.xml ! make/data/cldr/common/main/es_MX.xml ! make/data/cldr/common/main/es_NI.xml ! make/data/cldr/common/main/es_PA.xml ! make/data/cldr/common/main/es_PE.xml ! make/data/cldr/common/main/es_PH.xml ! make/data/cldr/common/main/es_PR.xml ! make/data/cldr/common/main/es_PY.xml ! make/data/cldr/common/main/es_SV.xml ! make/data/cldr/common/main/es_US.xml ! make/data/cldr/common/main/es_UY.xml ! make/data/cldr/common/main/es_VE.xml ! make/data/cldr/common/main/et.xml ! make/data/cldr/common/main/et_EE.xml ! make/data/cldr/common/main/eu.xml ! make/data/cldr/common/main/eu_ES.xml ! make/data/cldr/common/main/ewo.xml ! make/data/cldr/common/main/ewo_CM.xml ! make/data/cldr/common/main/fa.xml ! make/data/cldr/common/main/fa_AF.xml ! make/data/cldr/common/main/fa_IR.xml ! make/data/cldr/common/main/ff.xml ! make/data/cldr/common/main/ff_Adlm.xml ! make/data/cldr/common/main/ff_Adlm_BF.xml ! make/data/cldr/common/main/ff_Adlm_CM.xml ! make/data/cldr/common/main/ff_Adlm_GH.xml ! make/data/cldr/common/main/ff_Adlm_GM.xml ! make/data/cldr/common/main/ff_Adlm_GN.xml ! make/data/cldr/common/main/ff_Adlm_GW.xml ! make/data/cldr/common/main/ff_Adlm_LR.xml ! make/data/cldr/common/main/ff_Adlm_MR.xml ! make/data/cldr/common/main/ff_Adlm_NE.xml ! make/data/cldr/common/main/ff_Adlm_NG.xml ! make/data/cldr/common/main/ff_Adlm_SL.xml ! make/data/cldr/common/main/ff_Adlm_SN.xml ! make/data/cldr/common/main/ff_Latn.xml ! make/data/cldr/common/main/ff_Latn_BF.xml ! make/data/cldr/common/main/ff_Latn_CM.xml ! make/data/cldr/common/main/ff_Latn_GH.xml ! make/data/cldr/common/main/ff_Latn_GM.xml ! make/data/cldr/common/main/ff_Latn_GN.xml ! make/data/cldr/common/main/ff_Latn_GW.xml ! make/data/cldr/common/main/ff_Latn_LR.xml ! make/data/cldr/common/main/ff_Latn_MR.xml ! make/data/cldr/common/main/ff_Latn_NE.xml ! make/data/cldr/common/main/ff_Latn_NG.xml ! make/data/cldr/common/main/ff_Latn_SL.xml ! make/data/cldr/common/main/ff_Latn_SN.xml ! make/data/cldr/common/main/fi.xml ! make/data/cldr/common/main/fi_FI.xml ! make/data/cldr/common/main/fil.xml ! make/data/cldr/common/main/fil_PH.xml ! make/data/cldr/common/main/fo.xml ! make/data/cldr/common/main/fo_DK.xml ! make/data/cldr/common/main/fo_FO.xml ! make/data/cldr/common/main/fr.xml ! make/data/cldr/common/main/fr_BE.xml ! make/data/cldr/common/main/fr_BF.xml ! make/data/cldr/common/main/fr_BI.xml ! make/data/cldr/common/main/fr_BJ.xml ! make/data/cldr/common/main/fr_BL.xml ! make/data/cldr/common/main/fr_CA.xml ! make/data/cldr/common/main/fr_CD.xml ! make/data/cldr/common/main/fr_CF.xml ! make/data/cldr/common/main/fr_CG.xml ! make/data/cldr/common/main/fr_CH.xml ! make/data/cldr/common/main/fr_CI.xml ! make/data/cldr/common/main/fr_CM.xml ! make/data/cldr/common/main/fr_DJ.xml ! make/data/cldr/common/main/fr_DZ.xml ! make/data/cldr/common/main/fr_FR.xml ! make/data/cldr/common/main/fr_GA.xml ! make/data/cldr/common/main/fr_GF.xml ! make/data/cldr/common/main/fr_GN.xml ! make/data/cldr/common/main/fr_GP.xml ! make/data/cldr/common/main/fr_GQ.xml ! make/data/cldr/common/main/fr_HT.xml ! make/data/cldr/common/main/fr_KM.xml ! make/data/cldr/common/main/fr_LU.xml ! make/data/cldr/common/main/fr_MA.xml ! make/data/cldr/common/main/fr_MC.xml ! make/data/cldr/common/main/fr_MF.xml ! make/data/cldr/common/main/fr_MG.xml ! make/data/cldr/common/main/fr_ML.xml ! make/data/cldr/common/main/fr_MQ.xml ! make/data/cldr/common/main/fr_MR.xml ! make/data/cldr/common/main/fr_MU.xml ! make/data/cldr/common/main/fr_NC.xml ! make/data/cldr/common/main/fr_NE.xml ! make/data/cldr/common/main/fr_PF.xml ! make/data/cldr/common/main/fr_PM.xml ! make/data/cldr/common/main/fr_RE.xml ! make/data/cldr/common/main/fr_RW.xml ! make/data/cldr/common/main/fr_SC.xml ! make/data/cldr/common/main/fr_SN.xml ! make/data/cldr/common/main/fr_SY.xml ! make/data/cldr/common/main/fr_TD.xml ! make/data/cldr/common/main/fr_TG.xml ! make/data/cldr/common/main/fr_TN.xml ! make/data/cldr/common/main/fr_VU.xml ! make/data/cldr/common/main/fr_WF.xml ! make/data/cldr/common/main/fr_YT.xml ! make/data/cldr/common/main/frr.xml ! make/data/cldr/common/main/frr_DE.xml ! make/data/cldr/common/main/fur.xml ! make/data/cldr/common/main/fur_IT.xml ! make/data/cldr/common/main/fy.xml ! make/data/cldr/common/main/fy_NL.xml ! make/data/cldr/common/main/ga.xml ! make/data/cldr/common/main/ga_GB.xml ! make/data/cldr/common/main/ga_IE.xml ! make/data/cldr/common/main/gaa.xml ! make/data/cldr/common/main/gaa_GH.xml ! make/data/cldr/common/main/gd.xml ! make/data/cldr/common/main/gd_GB.xml ! make/data/cldr/common/main/gez.xml ! make/data/cldr/common/main/gez_ER.xml ! make/data/cldr/common/main/gez_ET.xml ! make/data/cldr/common/main/gl.xml ! make/data/cldr/common/main/gl_ES.xml ! make/data/cldr/common/main/gn.xml ! make/data/cldr/common/main/gn_PY.xml ! make/data/cldr/common/main/gsw.xml ! make/data/cldr/common/main/gsw_CH.xml ! make/data/cldr/common/main/gsw_FR.xml ! make/data/cldr/common/main/gsw_LI.xml ! make/data/cldr/common/main/gu.xml ! make/data/cldr/common/main/gu_IN.xml ! make/data/cldr/common/main/guz.xml ! make/data/cldr/common/main/guz_KE.xml ! make/data/cldr/common/main/gv.xml ! make/data/cldr/common/main/gv_IM.xml ! make/data/cldr/common/main/ha.xml ! make/data/cldr/common/main/ha_Arab.xml ! make/data/cldr/common/main/ha_Arab_NG.xml ! make/data/cldr/common/main/ha_Arab_SD.xml ! make/data/cldr/common/main/ha_GH.xml ! make/data/cldr/common/main/ha_NE.xml ! make/data/cldr/common/main/ha_NG.xml ! make/data/cldr/common/main/haw.xml ! make/data/cldr/common/main/haw_US.xml ! make/data/cldr/common/main/he.xml ! make/data/cldr/common/main/he_IL.xml ! make/data/cldr/common/main/hi.xml ! make/data/cldr/common/main/hi_IN.xml ! make/data/cldr/common/main/hi_Latn.xml ! make/data/cldr/common/main/hi_Latn_IN.xml ! make/data/cldr/common/main/hnj.xml ! make/data/cldr/common/main/hnj_Hmnp.xml ! make/data/cldr/common/main/hnj_Hmnp_US.xml ! make/data/cldr/common/main/hr.xml ! make/data/cldr/common/main/hr_BA.xml ! make/data/cldr/common/main/hr_HR.xml ! make/data/cldr/common/main/hsb.xml ! make/data/cldr/common/main/hsb_DE.xml ! make/data/cldr/common/main/hu.xml ! make/data/cldr/common/main/hu_HU.xml ! make/data/cldr/common/main/hy.xml ! make/data/cldr/common/main/hy_AM.xml ! make/data/cldr/common/main/ia.xml ! make/data/cldr/common/main/ia_001.xml ! make/data/cldr/common/main/id.xml ! make/data/cldr/common/main/id_ID.xml ! make/data/cldr/common/main/ie.xml ! make/data/cldr/common/main/ie_EE.xml ! make/data/cldr/common/main/ig.xml ! make/data/cldr/common/main/ig_NG.xml ! make/data/cldr/common/main/ii.xml ! make/data/cldr/common/main/ii_CN.xml ! make/data/cldr/common/main/io.xml ! make/data/cldr/common/main/io_001.xml ! make/data/cldr/common/main/is.xml ! make/data/cldr/common/main/is_IS.xml ! make/data/cldr/common/main/it.xml ! make/data/cldr/common/main/it_CH.xml ! make/data/cldr/common/main/it_IT.xml ! make/data/cldr/common/main/it_SM.xml ! make/data/cldr/common/main/it_VA.xml ! make/data/cldr/common/main/iu.xml ! make/data/cldr/common/main/iu_CA.xml ! make/data/cldr/common/main/iu_Latn.xml ! make/data/cldr/common/main/iu_Latn_CA.xml ! make/data/cldr/common/main/ja.xml ! make/data/cldr/common/main/ja_JP.xml ! make/data/cldr/common/main/jbo.xml ! make/data/cldr/common/main/jbo_001.xml ! make/data/cldr/common/main/jgo.xml ! make/data/cldr/common/main/jgo_CM.xml ! make/data/cldr/common/main/jmc.xml ! make/data/cldr/common/main/jmc_TZ.xml ! make/data/cldr/common/main/jv.xml ! make/data/cldr/common/main/jv_ID.xml ! make/data/cldr/common/main/ka.xml ! make/data/cldr/common/main/ka_GE.xml ! make/data/cldr/common/main/kab.xml ! make/data/cldr/common/main/kab_DZ.xml ! make/data/cldr/common/main/kaj.xml ! make/data/cldr/common/main/kaj_NG.xml ! make/data/cldr/common/main/kam.xml ! make/data/cldr/common/main/kam_KE.xml ! make/data/cldr/common/main/kcg.xml ! make/data/cldr/common/main/kcg_NG.xml ! make/data/cldr/common/main/kde.xml ! make/data/cldr/common/main/kde_TZ.xml ! make/data/cldr/common/main/kea.xml ! make/data/cldr/common/main/kea_CV.xml ! make/data/cldr/common/main/ken.xml ! make/data/cldr/common/main/ken_CM.xml ! make/data/cldr/common/main/kgp.xml ! make/data/cldr/common/main/kgp_BR.xml ! make/data/cldr/common/main/khq.xml ! make/data/cldr/common/main/khq_ML.xml ! make/data/cldr/common/main/ki.xml ! make/data/cldr/common/main/ki_KE.xml ! make/data/cldr/common/main/kk.xml ! make/data/cldr/common/main/kk_KZ.xml ! make/data/cldr/common/main/kkj.xml ! make/data/cldr/common/main/kkj_CM.xml ! make/data/cldr/common/main/kl.xml ! make/data/cldr/common/main/kl_GL.xml ! make/data/cldr/common/main/kln.xml ! make/data/cldr/common/main/kln_KE.xml ! make/data/cldr/common/main/km.xml ! make/data/cldr/common/main/km_KH.xml ! make/data/cldr/common/main/kn.xml ! make/data/cldr/common/main/kn_IN.xml ! make/data/cldr/common/main/ko.xml ! make/data/cldr/common/main/ko_CN.xml ! make/data/cldr/common/main/ko_KP.xml ! make/data/cldr/common/main/ko_KR.xml ! make/data/cldr/common/main/kok.xml ! make/data/cldr/common/main/kok_IN.xml ! make/data/cldr/common/main/kpe.xml ! make/data/cldr/common/main/kpe_GN.xml ! make/data/cldr/common/main/kpe_LR.xml ! make/data/cldr/common/main/ks.xml ! make/data/cldr/common/main/ks_Arab.xml ! make/data/cldr/common/main/ks_Arab_IN.xml ! make/data/cldr/common/main/ks_Deva.xml ! make/data/cldr/common/main/ks_Deva_IN.xml ! make/data/cldr/common/main/ksb.xml ! make/data/cldr/common/main/ksb_TZ.xml ! make/data/cldr/common/main/ksf.xml ! make/data/cldr/common/main/ksf_CM.xml ! make/data/cldr/common/main/ksh.xml ! make/data/cldr/common/main/ksh_DE.xml ! make/data/cldr/common/main/ku.xml ! make/data/cldr/common/main/ku_TR.xml ! make/data/cldr/common/main/kw.xml ! make/data/cldr/common/main/kw_GB.xml ! make/data/cldr/common/main/kxv.xml ! make/data/cldr/common/main/kxv_Deva.xml ! make/data/cldr/common/main/kxv_Deva_IN.xml ! make/data/cldr/common/main/kxv_Latn.xml ! make/data/cldr/common/main/kxv_Latn_IN.xml ! make/data/cldr/common/main/kxv_Orya.xml ! make/data/cldr/common/main/kxv_Orya_IN.xml ! make/data/cldr/common/main/kxv_Telu.xml ! make/data/cldr/common/main/kxv_Telu_IN.xml ! make/data/cldr/common/main/ky.xml ! make/data/cldr/common/main/ky_KG.xml ! make/data/cldr/common/main/la.xml ! make/data/cldr/common/main/la_VA.xml ! make/data/cldr/common/main/lag.xml ! make/data/cldr/common/main/lag_TZ.xml ! make/data/cldr/common/main/lb.xml ! make/data/cldr/common/main/lb_LU.xml ! make/data/cldr/common/main/lg.xml ! make/data/cldr/common/main/lg_UG.xml ! make/data/cldr/common/main/lij.xml ! make/data/cldr/common/main/lij_IT.xml ! make/data/cldr/common/main/lkt.xml ! make/data/cldr/common/main/lkt_US.xml ! make/data/cldr/common/main/lmo.xml ! make/data/cldr/common/main/lmo_IT.xml ! make/data/cldr/common/main/ln.xml ! make/data/cldr/common/main/ln_AO.xml ! make/data/cldr/common/main/ln_CD.xml ! make/data/cldr/common/main/ln_CF.xml ! make/data/cldr/common/main/ln_CG.xml ! make/data/cldr/common/main/lo.xml ! make/data/cldr/common/main/lo_LA.xml ! make/data/cldr/common/main/lrc.xml ! make/data/cldr/common/main/lrc_IQ.xml ! make/data/cldr/common/main/lrc_IR.xml ! make/data/cldr/common/main/lt.xml ! make/data/cldr/common/main/lt_LT.xml ! make/data/cldr/common/main/lu.xml ! make/data/cldr/common/main/lu_CD.xml ! make/data/cldr/common/main/luo.xml ! make/data/cldr/common/main/luo_KE.xml ! make/data/cldr/common/main/luy.xml ! make/data/cldr/common/main/luy_KE.xml ! make/data/cldr/common/main/lv.xml ! make/data/cldr/common/main/lv_LV.xml ! make/data/cldr/common/main/mai.xml ! make/data/cldr/common/main/mai_IN.xml ! make/data/cldr/common/main/mas.xml ! make/data/cldr/common/main/mas_KE.xml ! make/data/cldr/common/main/mas_TZ.xml ! make/data/cldr/common/main/mdf.xml ! make/data/cldr/common/main/mdf_RU.xml ! make/data/cldr/common/main/mer.xml ! make/data/cldr/common/main/mer_KE.xml ! make/data/cldr/common/main/mfe.xml ! make/data/cldr/common/main/mfe_MU.xml ! make/data/cldr/common/main/mg.xml ! make/data/cldr/common/main/mg_MG.xml ! make/data/cldr/common/main/mgh.xml ! make/data/cldr/common/main/mgh_MZ.xml ! make/data/cldr/common/main/mgo.xml ! make/data/cldr/common/main/mgo_CM.xml ! make/data/cldr/common/main/mi.xml ! make/data/cldr/common/main/mi_NZ.xml ! make/data/cldr/common/main/mic.xml ! make/data/cldr/common/main/mic_CA.xml ! make/data/cldr/common/main/mk.xml ! make/data/cldr/common/main/mk_MK.xml ! make/data/cldr/common/main/ml.xml ! make/data/cldr/common/main/ml_IN.xml ! make/data/cldr/common/main/mn.xml ! make/data/cldr/common/main/mn_MN.xml ! make/data/cldr/common/main/mn_Mong.xml ! make/data/cldr/common/main/mn_Mong_CN.xml ! make/data/cldr/common/main/mn_Mong_MN.xml ! make/data/cldr/common/main/mni.xml ! make/data/cldr/common/main/mni_Beng.xml ! make/data/cldr/common/main/mni_Beng_IN.xml ! make/data/cldr/common/main/mni_Mtei.xml ! make/data/cldr/common/main/mni_Mtei_IN.xml ! make/data/cldr/common/main/moh.xml ! make/data/cldr/common/main/moh_CA.xml ! make/data/cldr/common/main/mr.xml ! make/data/cldr/common/main/mr_IN.xml ! make/data/cldr/common/main/ms.xml ! make/data/cldr/common/main/ms_Arab.xml ! make/data/cldr/common/main/ms_Arab_BN.xml ! make/data/cldr/common/main/ms_Arab_MY.xml ! make/data/cldr/common/main/ms_BN.xml ! make/data/cldr/common/main/ms_ID.xml ! make/data/cldr/common/main/ms_MY.xml ! make/data/cldr/common/main/ms_SG.xml ! make/data/cldr/common/main/mt.xml ! make/data/cldr/common/main/mt_MT.xml ! make/data/cldr/common/main/mua.xml ! make/data/cldr/common/main/mua_CM.xml ! make/data/cldr/common/main/mus.xml ! make/data/cldr/common/main/mus_US.xml ! make/data/cldr/common/main/my.xml ! make/data/cldr/common/main/my_MM.xml ! make/data/cldr/common/main/myv.xml ! make/data/cldr/common/main/myv_RU.xml ! make/data/cldr/common/main/mzn.xml ! make/data/cldr/common/main/mzn_IR.xml ! make/data/cldr/common/main/naq.xml ! make/data/cldr/common/main/naq_NA.xml ! make/data/cldr/common/main/nb.xml ! make/data/cldr/common/main/nb_NO.xml ! make/data/cldr/common/main/nb_SJ.xml ! make/data/cldr/common/main/nd.xml ! make/data/cldr/common/main/nd_ZW.xml ! make/data/cldr/common/main/nds.xml ! make/data/cldr/common/main/nds_DE.xml ! make/data/cldr/common/main/nds_NL.xml ! make/data/cldr/common/main/ne.xml ! make/data/cldr/common/main/ne_IN.xml ! make/data/cldr/common/main/ne_NP.xml ! make/data/cldr/common/main/nl.xml ! make/data/cldr/common/main/nl_AW.xml ! make/data/cldr/common/main/nl_BE.xml ! make/data/cldr/common/main/nl_BQ.xml ! make/data/cldr/common/main/nl_CW.xml ! make/data/cldr/common/main/nl_NL.xml ! make/data/cldr/common/main/nl_SR.xml ! make/data/cldr/common/main/nl_SX.xml ! make/data/cldr/common/main/nmg.xml ! make/data/cldr/common/main/nmg_CM.xml ! make/data/cldr/common/main/nn.xml ! make/data/cldr/common/main/nn_NO.xml ! make/data/cldr/common/main/nnh.xml ! make/data/cldr/common/main/nnh_CM.xml ! make/data/cldr/common/main/no.xml ! make/data/cldr/common/main/nqo.xml ! make/data/cldr/common/main/nqo_GN.xml ! make/data/cldr/common/main/nr.xml ! make/data/cldr/common/main/nr_ZA.xml ! make/data/cldr/common/main/nso.xml ! make/data/cldr/common/main/nso_ZA.xml ! make/data/cldr/common/main/nus.xml ! make/data/cldr/common/main/nus_SS.xml ! make/data/cldr/common/main/nv.xml ! make/data/cldr/common/main/nv_US.xml ! make/data/cldr/common/main/ny.xml ! make/data/cldr/common/main/ny_MW.xml ! make/data/cldr/common/main/nyn.xml ! make/data/cldr/common/main/nyn_UG.xml ! make/data/cldr/common/main/oc.xml ! make/data/cldr/common/main/oc_ES.xml ! make/data/cldr/common/main/oc_FR.xml ! make/data/cldr/common/main/om.xml ! make/data/cldr/common/main/om_ET.xml ! make/data/cldr/common/main/om_KE.xml ! make/data/cldr/common/main/or.xml ! make/data/cldr/common/main/or_IN.xml ! make/data/cldr/common/main/os.xml ! make/data/cldr/common/main/os_GE.xml ! make/data/cldr/common/main/os_RU.xml ! make/data/cldr/common/main/osa.xml ! make/data/cldr/common/main/osa_US.xml ! make/data/cldr/common/main/pa.xml ! make/data/cldr/common/main/pa_Arab.xml ! make/data/cldr/common/main/pa_Arab_PK.xml ! make/data/cldr/common/main/pa_Guru.xml ! make/data/cldr/common/main/pa_Guru_IN.xml ! make/data/cldr/common/main/pap.xml ! make/data/cldr/common/main/pap_AW.xml ! make/data/cldr/common/main/pap_CW.xml ! make/data/cldr/common/main/pcm.xml ! make/data/cldr/common/main/pcm_NG.xml ! make/data/cldr/common/main/pis.xml ! make/data/cldr/common/main/pis_SB.xml ! make/data/cldr/common/main/pl.xml ! make/data/cldr/common/main/pl_PL.xml ! make/data/cldr/common/main/prg.xml ! make/data/cldr/common/main/prg_PL.xml ! make/data/cldr/common/main/ps.xml ! make/data/cldr/common/main/ps_AF.xml ! make/data/cldr/common/main/ps_PK.xml ! make/data/cldr/common/main/pt.xml ! make/data/cldr/common/main/pt_AO.xml ! make/data/cldr/common/main/pt_BR.xml ! make/data/cldr/common/main/pt_CH.xml ! make/data/cldr/common/main/pt_CV.xml ! make/data/cldr/common/main/pt_GQ.xml ! make/data/cldr/common/main/pt_GW.xml ! make/data/cldr/common/main/pt_LU.xml ! make/data/cldr/common/main/pt_MO.xml ! make/data/cldr/common/main/pt_MZ.xml ! make/data/cldr/common/main/pt_PT.xml ! make/data/cldr/common/main/pt_ST.xml ! make/data/cldr/common/main/pt_TL.xml ! make/data/cldr/common/main/qu.xml ! make/data/cldr/common/main/qu_BO.xml ! make/data/cldr/common/main/qu_EC.xml ! make/data/cldr/common/main/qu_PE.xml ! make/data/cldr/common/main/quc.xml ! make/data/cldr/common/main/quc_GT.xml ! make/data/cldr/common/main/raj.xml ! make/data/cldr/common/main/raj_IN.xml ! make/data/cldr/common/main/rhg.xml ! make/data/cldr/common/main/rhg_Rohg.xml ! make/data/cldr/common/main/rhg_Rohg_BD.xml ! make/data/cldr/common/main/rhg_Rohg_MM.xml ! make/data/cldr/common/main/rif.xml ! make/data/cldr/common/main/rif_MA.xml ! make/data/cldr/common/main/rm.xml ! make/data/cldr/common/main/rm_CH.xml ! make/data/cldr/common/main/rn.xml ! make/data/cldr/common/main/rn_BI.xml ! make/data/cldr/common/main/ro.xml ! make/data/cldr/common/main/ro_MD.xml ! make/data/cldr/common/main/ro_RO.xml ! make/data/cldr/common/main/rof.xml ! make/data/cldr/common/main/rof_TZ.xml ! make/data/cldr/common/main/root.xml ! make/data/cldr/common/main/ru.xml ! make/data/cldr/common/main/ru_BY.xml ! make/data/cldr/common/main/ru_KG.xml ! make/data/cldr/common/main/ru_KZ.xml ! make/data/cldr/common/main/ru_MD.xml ! make/data/cldr/common/main/ru_RU.xml ! make/data/cldr/common/main/ru_UA.xml ! make/data/cldr/common/main/rw.xml ! make/data/cldr/common/main/rw_RW.xml ! make/data/cldr/common/main/rwk.xml ! make/data/cldr/common/main/rwk_TZ.xml ! make/data/cldr/common/main/sa.xml ! make/data/cldr/common/main/sa_IN.xml ! make/data/cldr/common/main/sah.xml ! make/data/cldr/common/main/sah_RU.xml ! make/data/cldr/common/main/saq.xml ! make/data/cldr/common/main/saq_KE.xml ! make/data/cldr/common/main/sat.xml ! make/data/cldr/common/main/sat_Deva.xml ! make/data/cldr/common/main/sat_Deva_IN.xml ! make/data/cldr/common/main/sat_Olck.xml ! make/data/cldr/common/main/sat_Olck_IN.xml ! make/data/cldr/common/main/sbp.xml ! make/data/cldr/common/main/sbp_TZ.xml ! make/data/cldr/common/main/sc.xml ! make/data/cldr/common/main/sc_IT.xml ! make/data/cldr/common/main/scn.xml ! make/data/cldr/common/main/scn_IT.xml ! make/data/cldr/common/main/sd.xml ! make/data/cldr/common/main/sd_Arab.xml ! make/data/cldr/common/main/sd_Arab_PK.xml ! make/data/cldr/common/main/sd_Deva.xml ! make/data/cldr/common/main/sd_Deva_IN.xml ! make/data/cldr/common/main/sdh.xml ! make/data/cldr/common/main/sdh_IQ.xml ! make/data/cldr/common/main/sdh_IR.xml ! make/data/cldr/common/main/se.xml ! make/data/cldr/common/main/se_FI.xml ! make/data/cldr/common/main/se_NO.xml ! make/data/cldr/common/main/se_SE.xml ! make/data/cldr/common/main/seh.xml ! make/data/cldr/common/main/seh_MZ.xml ! make/data/cldr/common/main/ses.xml ! make/data/cldr/common/main/ses_ML.xml ! make/data/cldr/common/main/sg.xml ! make/data/cldr/common/main/sg_CF.xml ! make/data/cldr/common/main/shi.xml ! make/data/cldr/common/main/shi_Latn.xml ! make/data/cldr/common/main/shi_Latn_MA.xml ! make/data/cldr/common/main/shi_Tfng.xml ! make/data/cldr/common/main/shi_Tfng_MA.xml ! make/data/cldr/common/main/shn.xml ! make/data/cldr/common/main/shn_MM.xml ! make/data/cldr/common/main/shn_TH.xml ! make/data/cldr/common/main/si.xml ! make/data/cldr/common/main/si_LK.xml ! make/data/cldr/common/main/sid.xml ! make/data/cldr/common/main/sid_ET.xml ! make/data/cldr/common/main/sk.xml ! make/data/cldr/common/main/sk_SK.xml ! make/data/cldr/common/main/skr.xml ! make/data/cldr/common/main/skr_PK.xml ! make/data/cldr/common/main/sl.xml ! make/data/cldr/common/main/sl_SI.xml ! make/data/cldr/common/main/sma.xml ! make/data/cldr/common/main/sma_NO.xml ! make/data/cldr/common/main/sma_SE.xml ! make/data/cldr/common/main/smj.xml ! make/data/cldr/common/main/smj_NO.xml ! make/data/cldr/common/main/smj_SE.xml ! make/data/cldr/common/main/smn.xml ! make/data/cldr/common/main/smn_FI.xml ! make/data/cldr/common/main/sms.xml ! make/data/cldr/common/main/sms_FI.xml ! make/data/cldr/common/main/sn.xml ! make/data/cldr/common/main/sn_ZW.xml ! make/data/cldr/common/main/so.xml ! make/data/cldr/common/main/so_DJ.xml ! make/data/cldr/common/main/so_ET.xml ! make/data/cldr/common/main/so_KE.xml ! make/data/cldr/common/main/so_SO.xml ! make/data/cldr/common/main/sq.xml ! make/data/cldr/common/main/sq_AL.xml ! make/data/cldr/common/main/sq_MK.xml ! make/data/cldr/common/main/sq_XK.xml ! make/data/cldr/common/main/sr.xml ! make/data/cldr/common/main/sr_Cyrl.xml ! make/data/cldr/common/main/sr_Cyrl_BA.xml ! make/data/cldr/common/main/sr_Cyrl_ME.xml ! make/data/cldr/common/main/sr_Cyrl_RS.xml ! make/data/cldr/common/main/sr_Cyrl_XK.xml ! make/data/cldr/common/main/sr_Latn.xml ! make/data/cldr/common/main/sr_Latn_BA.xml ! make/data/cldr/common/main/sr_Latn_ME.xml ! make/data/cldr/common/main/sr_Latn_RS.xml ! make/data/cldr/common/main/sr_Latn_XK.xml ! make/data/cldr/common/main/ss.xml ! make/data/cldr/common/main/ss_SZ.xml ! make/data/cldr/common/main/ss_ZA.xml ! make/data/cldr/common/main/ssy.xml ! make/data/cldr/common/main/ssy_ER.xml ! make/data/cldr/common/main/st.xml ! make/data/cldr/common/main/st_LS.xml ! make/data/cldr/common/main/st_ZA.xml ! make/data/cldr/common/main/su.xml ! make/data/cldr/common/main/su_Latn.xml ! make/data/cldr/common/main/su_Latn_ID.xml ! make/data/cldr/common/main/sv.xml ! make/data/cldr/common/main/sv_AX.xml ! make/data/cldr/common/main/sv_FI.xml ! make/data/cldr/common/main/sv_SE.xml ! make/data/cldr/common/main/sw.xml ! make/data/cldr/common/main/sw_CD.xml ! make/data/cldr/common/main/sw_KE.xml ! make/data/cldr/common/main/sw_TZ.xml ! make/data/cldr/common/main/sw_UG.xml ! make/data/cldr/common/main/syr.xml ! make/data/cldr/common/main/syr_IQ.xml ! make/data/cldr/common/main/syr_SY.xml ! make/data/cldr/common/main/szl.xml ! make/data/cldr/common/main/szl_PL.xml ! make/data/cldr/common/main/ta.xml ! make/data/cldr/common/main/ta_IN.xml ! make/data/cldr/common/main/ta_LK.xml ! make/data/cldr/common/main/ta_MY.xml ! make/data/cldr/common/main/ta_SG.xml ! make/data/cldr/common/main/te.xml ! make/data/cldr/common/main/te_IN.xml ! make/data/cldr/common/main/teo.xml ! make/data/cldr/common/main/teo_KE.xml ! make/data/cldr/common/main/teo_UG.xml ! make/data/cldr/common/main/tg.xml ! make/data/cldr/common/main/tg_TJ.xml ! make/data/cldr/common/main/th.xml ! make/data/cldr/common/main/th_TH.xml ! make/data/cldr/common/main/ti.xml ! make/data/cldr/common/main/ti_ER.xml ! make/data/cldr/common/main/ti_ET.xml ! make/data/cldr/common/main/tig.xml ! make/data/cldr/common/main/tig_ER.xml ! make/data/cldr/common/main/tk.xml ! make/data/cldr/common/main/tk_TM.xml ! make/data/cldr/common/main/tn.xml ! make/data/cldr/common/main/tn_BW.xml ! make/data/cldr/common/main/tn_ZA.xml ! make/data/cldr/common/main/to.xml ! make/data/cldr/common/main/to_TO.xml ! make/data/cldr/common/main/tok.xml ! make/data/cldr/common/main/tok_001.xml ! make/data/cldr/common/main/tpi.xml ! make/data/cldr/common/main/tpi_PG.xml ! make/data/cldr/common/main/tr.xml ! make/data/cldr/common/main/tr_CY.xml ! make/data/cldr/common/main/tr_TR.xml ! make/data/cldr/common/main/trv.xml ! make/data/cldr/common/main/trv_TW.xml ! make/data/cldr/common/main/trw.xml ! make/data/cldr/common/main/trw_PK.xml ! make/data/cldr/common/main/ts.xml ! make/data/cldr/common/main/ts_ZA.xml ! make/data/cldr/common/main/tt.xml ! make/data/cldr/common/main/tt_RU.xml ! make/data/cldr/common/main/twq.xml ! make/data/cldr/common/main/twq_NE.xml ! make/data/cldr/common/main/tyv.xml ! make/data/cldr/common/main/tyv_RU.xml ! make/data/cldr/common/main/tzm.xml ! make/data/cldr/common/main/tzm_MA.xml ! make/data/cldr/common/main/ug.xml ! make/data/cldr/common/main/ug_CN.xml ! make/data/cldr/common/main/uk.xml ! make/data/cldr/common/main/uk_UA.xml ! make/data/cldr/common/main/ur.xml ! make/data/cldr/common/main/ur_IN.xml ! make/data/cldr/common/main/ur_PK.xml ! make/data/cldr/common/main/uz.xml ! make/data/cldr/common/main/uz_Arab.xml ! make/data/cldr/common/main/uz_Arab_AF.xml ! make/data/cldr/common/main/uz_Cyrl.xml ! make/data/cldr/common/main/uz_Cyrl_UZ.xml ! make/data/cldr/common/main/uz_Latn.xml ! make/data/cldr/common/main/uz_Latn_UZ.xml ! make/data/cldr/common/main/vai.xml ! make/data/cldr/common/main/vai_Latn.xml ! make/data/cldr/common/main/vai_Latn_LR.xml ! make/data/cldr/common/main/vai_Vaii.xml ! make/data/cldr/common/main/vai_Vaii_LR.xml ! make/data/cldr/common/main/ve.xml ! make/data/cldr/common/main/ve_ZA.xml ! make/data/cldr/common/main/vec.xml ! make/data/cldr/common/main/vec_IT.xml ! make/data/cldr/common/main/vi.xml ! make/data/cldr/common/main/vi_VN.xml ! make/data/cldr/common/main/vmw.xml ! make/data/cldr/common/main/vmw_MZ.xml ! make/data/cldr/common/main/vo.xml ! make/data/cldr/common/main/vo_001.xml ! make/data/cldr/common/main/vun.xml ! make/data/cldr/common/main/vun_TZ.xml ! make/data/cldr/common/main/wa.xml ! make/data/cldr/common/main/wa_BE.xml ! make/data/cldr/common/main/wae.xml ! make/data/cldr/common/main/wae_CH.xml ! make/data/cldr/common/main/wal.xml ! make/data/cldr/common/main/wal_ET.xml ! make/data/cldr/common/main/wbp.xml ! make/data/cldr/common/main/wbp_AU.xml ! make/data/cldr/common/main/wo.xml ! make/data/cldr/common/main/wo_SN.xml ! make/data/cldr/common/main/xh.xml ! make/data/cldr/common/main/xh_ZA.xml ! make/data/cldr/common/main/xnr.xml ! make/data/cldr/common/main/xnr_IN.xml ! make/data/cldr/common/main/xog.xml ! make/data/cldr/common/main/xog_UG.xml ! make/data/cldr/common/main/yav.xml ! make/data/cldr/common/main/yav_CM.xml ! make/data/cldr/common/main/yi.xml ! make/data/cldr/common/main/yi_UA.xml ! make/data/cldr/common/main/yo.xml ! make/data/cldr/common/main/yo_BJ.xml ! make/data/cldr/common/main/yo_NG.xml ! make/data/cldr/common/main/yrl.xml ! make/data/cldr/common/main/yrl_BR.xml ! make/data/cldr/common/main/yrl_CO.xml ! make/data/cldr/common/main/yrl_VE.xml ! make/data/cldr/common/main/yue.xml ! make/data/cldr/common/main/yue_Hans.xml ! make/data/cldr/common/main/yue_Hans_CN.xml ! make/data/cldr/common/main/yue_Hant.xml ! make/data/cldr/common/main/yue_Hant_HK.xml ! make/data/cldr/common/main/za.xml ! make/data/cldr/common/main/za_CN.xml ! make/data/cldr/common/main/zgh.xml ! make/data/cldr/common/main/zgh_MA.xml ! make/data/cldr/common/main/zh.xml ! make/data/cldr/common/main/zh_Hans.xml ! make/data/cldr/common/main/zh_Hans_CN.xml ! make/data/cldr/common/main/zh_Hans_HK.xml ! make/data/cldr/common/main/zh_Hans_MO.xml ! make/data/cldr/common/main/zh_Hans_SG.xml ! make/data/cldr/common/main/zh_Hant.xml ! make/data/cldr/common/main/zh_Hant_HK.xml ! make/data/cldr/common/main/zh_Hant_MO.xml ! make/data/cldr/common/main/zh_Hant_TW.xml ! make/data/cldr/common/main/zu.xml ! make/data/cldr/common/main/zu_ZA.xml ! make/data/cldr/common/properties/coverageLevels.txt ! make/data/cldr/common/supplemental/coverageLevels.xml ! make/data/cldr/common/supplemental/languageGroup.xml ! make/data/cldr/common/supplemental/languageInfo.xml ! make/data/cldr/common/supplemental/likelySubtags.xml ! make/data/cldr/common/supplemental/metaZones.xml ! make/data/cldr/common/supplemental/ordinals.xml ! make/data/cldr/common/supplemental/pluralRanges.xml ! make/data/cldr/common/supplemental/plurals.xml ! make/data/cldr/common/supplemental/subdivisions.xml ! make/data/cldr/common/supplemental/supplementalData.xml ! make/data/cldr/common/supplemental/supplementalMetadata.xml ! make/data/cldr/common/supplemental/units.xml ! make/data/cldr/common/supplemental/windowsZones.xml ! src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java ! src/java.base/share/legal/cldr.md ! src/jdk.localedata/share/legal/cldr.md ! test/jdk/java/text/Format/CompactNumberFormat/TestCompactNumber.java ! test/jdk/java/text/Format/CompactNumberFormat/TestParseBigDecimal.java Changeset: b3bcc494 Author: Vladimir Kozlov Date: 2024-04-25 22:46:11 +0000 URL: https://git.openjdk.org/leyden/commit/b3bcc49491b8f8ad337eb4c06201a5468e5c1159 8330181: Move PcDesc cache from nmethod header Reviewed-by: dlong, jrose ! src/hotspot/os/posix/signals_posix.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp Changeset: 5a39b00d Author: iklam Date: 2024-04-25 22:33:48 +0000 URL: https://git.openjdk.org/leyden/commit/5a39b00d73e36ca505a009857edfce2939e61f60 Merge branch 'master' of https://github.com/openjdk/leyden into premain ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp ! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_Runtime1.cpp ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveBuilder.hpp ! src/hotspot/share/cds/classListParser.cpp ! src/hotspot/share/cds/classPrelinker.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/code/debugInfoRec.cpp ! src/hotspot/share/code/dependencies.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compilerDefinitions.hpp ! src/hotspot/share/compiler/compilerDirectives.hpp ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/compiler/compilerOracle.hpp ! src/hotspot/share/compiler/methodMatcher.cpp ! src/hotspot/share/interpreter/bytecodeTracer.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/rewriter.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/constantPool.hpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/oops/methodCounters.cpp ! src/hotspot/share/oops/methodCounters.hpp ! src/hotspot/share/oops/methodData.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/runtime.hpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/prims/unsafe.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/threads.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/runtime/vmThread.hpp ! src/java.base/share/classes/java/lang/invoke/LambdaForm.java ! src/java.base/share/native/libzip/zip_util.c ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp ! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_Runtime1.cpp ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveBuilder.hpp ! src/hotspot/share/cds/classListParser.cpp ! src/hotspot/share/cds/classPrelinker.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/code/debugInfoRec.cpp ! src/hotspot/share/code/dependencies.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compilerDefinitions.hpp ! src/hotspot/share/compiler/compilerDirectives.hpp ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/compiler/compilerOracle.hpp ! src/hotspot/share/compiler/methodMatcher.cpp ! src/hotspot/share/interpreter/bytecodeTracer.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/rewriter.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/constantPool.hpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/oops/methodCounters.cpp ! src/hotspot/share/oops/methodCounters.hpp ! src/hotspot/share/oops/methodData.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/runtime.hpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/prims/unsafe.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/threads.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/runtime/vmThread.hpp ! src/java.base/share/classes/java/lang/invoke/LambdaForm.java ! src/java.base/share/native/libzip/zip_util.c Changeset: ba07d82a Author: iklam Date: 2024-04-26 08:57:07 +0000 URL: https://git.openjdk.org/leyden/commit/ba07d82a0008659af7cf222f8e91605ee03b79dc Merge branch 'premain' of https://github.com/openjdk/leyden into premain ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveBuilder.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveBuilder.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/runtime/arguments.cpp From duke at openjdk.org Mon Apr 29 21:07:34 2024 From: duke at openjdk.org (duke) Date: Mon, 29 Apr 2024 21:07:34 GMT Subject: git: openjdk/leyden: premain: Copy contents of ProblemList-premain.txt to ProblemList.txt, in preparation of regular tiers1-3 testing Message-ID: <9d309f81-639c-428f-99ef-b65ee9c5ccf1@openjdk.org> Changeset: 674deded Author: iklam Date: 2024-04-29 13:59:34 +0000 URL: https://git.openjdk.org/leyden/commit/674deded47180a27a3401701239db16d22fe8a66 Copy contents of ProblemList-premain.txt to ProblemList.txt, in preparation of regular tiers1-3 testing ! test/hotspot/jtreg/ProblemList.txt From duke at openjdk.org Tue Apr 30 02:20:06 2024 From: duke at openjdk.org (duke) Date: Tue, 30 Apr 2024 02:20:06 GMT Subject: git: openjdk/leyden: premain: Disable CDS if runtime VM options are incompatible with archives dumped with -XX:+PreloadSharedClasses Message-ID: Changeset: 9076b74d Author: iklam Date: 2024-04-29 19:17:48 +0000 URL: https://git.openjdk.org/leyden/commit/9076b74d82778dbbd25a1a7e9ffa9ee0810a1111 Disable CDS if runtime VM options are incompatible with archives dumped with -XX:+PreloadSharedClasses ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! test/hotspot/jtreg/runtime/cds/appcds/jvmti/ClassFileLoadHookTest.java + test/hotspot/jtreg/runtime/cds/appcds/preloadedClasses/PreloadedClassesVMOptions.java = test/hotspot/jtreg/runtime/cds/appcds/preloadedClasses/PreloadedClassesVerification.java From magnus.ihse.bursie at oracle.com Tue Apr 30 12:42:07 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 30 Apr 2024 14:42:07 +0200 Subject: Hermetic Java project meeting In-Reply-To: References: <65fdda77-1291-437e-b000-ca0307cf8084@oracle.com> Message-ID: <779749fa-8427-4b48-b897-5210b36d5be8@oracle.com> On 2024-04-26 03:15, Jiangli Zhou wrote: > On Thu, Apr 25, 2024 at 9:28?AM Magnus Ihse Bursie > wrote: >> >> Just to be more clear, that's with using `objcopy` to localize non-exported symbols for all JDK static libraries and libjvm.a, not just libjvm.a right? >> >> Yes. >> >> >> Can you please include the compiler or linker errors on linux/clang? >> >> It is a bit tricky. The problem arises at the partial linking step. The problem seem to arise out of how clang converts a request to link into an actual call to ld. I enabled debug code (printing the command line, and running clang with `-v` to get it to print the actual command line used to run ld) and ran it on GHA, where it worked fine. This is how it looks there: >> >> WILL_RUN: /usr/bin/clang -v -m64 -r -o /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/librmi_relocatable.o /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/GC.o >> Ubuntu clang version 14.0.0-1ubuntu1.1 >> Target: x86_64-pc-linux-gnu >> Thread model: posix >> InstalledDir: /usr/bin >> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/10 >> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/11 >> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/12 >> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13 >> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9 >> Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13 >> Candidate multilib: .;@m64 >> Selected multilib: .;@m64 >> "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/librmi_relocatable.o -L/usr/bin/../lib/gcc/x86_64-linux-gnu/13 -L/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/usr/lib/llvm-14/bin/../lib -L/lib -L/usr/lib -r /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/GC.o >> >> In contrast, on my machine it looks like this: >> >> WILL_RUN: /usr/local/clang+llvm-13.0.1-x86_64-linux-gnu-ubuntu-18.04/bin/clang -v -m64 -r -o /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/librmi_relocatable.o /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/GC.o >> clang version 13.0.1 >> Target: x86_64-unknown-linux-gnu >> Thread model: posix >> InstalledDir: /usr/local/clang+llvm-13.0.1-x86_64-linux-gnu-ubuntu-18.04/bin >> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9 >> Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9 >> Candidate multilib: .;@m64 >> Candidate multilib: 32;@m32 >> Candidate multilib: x32;@mx32 >> Selected multilib: .;@m64 >> "/usr/bin/ld" --hash-style=both --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/librmi_relocatable.o /lib/x86_64-linux-gnu/crt1.o /lib/x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/9/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/9 -L/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/usr/local/clang+llvm-13.0.1-x86_64-linux-gnu-ubuntu-18.04/bin/../lib -L/lib -L/usr/lib -r /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/GC.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/9/crtend.o /lib/x86_64-linux-gnu/crtn.o >> /usr/bin/ld: cannot find -lgcc_s >> /usr/bin/ld: cannot find -lgcc_s >> clang-13: error: linker command failed with exit code 1 (use -v to see invocation) >> >> I don't understand what makes clang think it should include "-lgcc --as-needed -lgcc_s" and the crt*.o files when doing a partial link. In fact, the entire process on how clang (and gcc) builds up the linker command line is bordering on black magic to me. I think it can be affected by variables set at compile time (at least this was the case for gcc, last I checked), or maybe it picks up some kind of script from the environment. That's why I believe my machine could just be messed up. >> >> I could get a bit further by passing "-nodefaultlibs" (or whatever it was), but then the generated .o file were messed up wrt to library symbols and it failed dramatically when trying to do the final link of the static java launcher. >> >> > Looks like you are using /usr/bin/ld and not lld. I haven't run into > this type of issue. Have you tried -fuse-ld=lld? I am not sure why clang insisted on picking up ld and not lld. I remeber trying with -fuse-ld=lld, and that it did not work either. Unfortunately, I don't remember exactly what the problems were. I started reinstalling my Linux workstation yesterday, but something went wrong, and it failed so hard that it got semi-bricked by the new installation, so I need to redo everything from scratch. :-( After that is done, I'll re-test. Hopefully this was just my old installation that was too broken. > >>> >>> I have also tried to extract all the changes (and only the changes) >>> related to static build from the hermetic-java-runtime branch (ignoring >>> the JavaHome/resource loading changes), to see if I could get something >>> like StaticLink.gmk in mainline. I thought I was doing quite fine, but >>> after a while I realized my testing was botched since the launcher had >>> actually loaded the libraries dynamically instead, even though they were >>> statically linked. :-( I am currently trying to bisect my way thought my >>> repo to understand where things went wrong. >> >> Did you run with `bin/javastatic`? The system automatically detects if the binary contains statically linked native libraries and avoids loading the dynamic libraries. Can you please share which test(s) ran into the library loading issue? I'll see if I can reproduce the problem that you are running into. >> >> It was in fact not a problem. I was fooled by an error message. To be sure I was not loading any dynamically linked libraries, I removed the jdk/lib directory. Now the launcher failed, saying something like: >> >> "Error: Cannot locate dynamic library libjava.dylib". >> >> which was a bit of a jump scare. >> >> However, it turned out that it actually tried to load lib/jvm.cfg, and failed in loading this (since I had removed the entire lib directory), and this failure caused the above error message to be printed. When I restored lib/jvm.cfg (but not any dynamic libraries), the launcher worked. >> > Sounds like you are running into problems immediately during startup. > Does the problem occur with just running bin/javastatic using a simple > HelloWorld? Can you please send me your command line for reproducing? Maybe I was not clear enough: I did resolve the problem. > For the static Java support, I changed CreateExecutionEnvironment to > return immediately if it executes statically. jvm.cfg is not loaded. > Please see https://github.com/openjdk/leyden/blob/c1c5fc686c1452550e1b3663a320fba652248505/src/java.base/unix/native/libjli/java_md.c#L296. > Sounds like the JLI_IsStaticJDK() check is not working properly in > your case. I've been trying to extract from your port a minimal set of patches that is needed to get static build to work. In that process, JavaHome and JLI_IsStaticJDK have been removed. It might be that this issue arised only in my slimmed-down branch, and not on your leyden branch (at this point I don't recall exactly). But, we need to fix this separately, since we must be able to build a static launcher without the hermetic changes. In my branch, I am only using compile-time #ifdef checks for static vs dynamic. In the long run, the runtime checks that you have done are a good thing, but at the moment they are just adding intrusive changes without providing any benefit -- if we can't reuse .o files between dynamic and static compilation, there is no point in introducing a runtime check when we already have a working compile-time check. I did think I correctly changed every dynamic check that you had added to a compile-time check, so it bewilders me somewhat when you say that jvm.cfg is not needed in your branch. Can you verify and confirm that the static launcher actually works in your branch, if there is no "lib/jvm.cfg" present? /Magnus > > Best, > Jiangli > >> There are several bugs lurking here. For once, the error message is incorrect and should be corrected. Secondly, a statically linked launcher has just a single JVM included and should not have to look for the lib/jvm.cfg file at all. >> >> After looking around a bit in the launcher/jli code, my conclusion is that this code will need some additional care and loving attention to make it properly adjusted to function as a static launcher. We can't have a static launcher that tries to load a jvm.cfg file it does not need, and when it fails, complains that it is missing a dynamic library that it should not load. >> >> I'll try to get this fixed as part of my efforts to get the static launcher into mainline. >>> This was done haphazardly in StaticLink.gmk in the hermetic-java-runtime >>> branch, where an arbitrary subset of external libraries were hard-coded. >>> Before integration in mainline can be possible, this information needs >>> to be collected correctly and automatically for all included JDK >>> libraries. Fortunately, it is not likely to be too hard. I basically >>> just need to store the information from the LIBS provided to the >>> NativeCompilation, and pick that up for all static libraries we include >>> in the static launcher. (A complication is that we need to de-duplicate >>> the list, and that some libraries are specified using two words, like >>> "-framework Application" on macos, so it will take some care getting it >>> right.) >> >> Right, currently the hermetic-java-runtime branch specifies a list of hard-coded dependency libraries for linking. One of the goals of the hermetic prototype was avoiding/reducing refactoring/restructuring the existing code whenever possible. The reason is to reduce merge overhead when integrating with new changes from the mainline. We can do the proper refactoring and cleanups when getting the changes into the mainline. >> >> That is basically what I am doing right now. I am looking at your prototype and trying to reimplement this functionality properly so that it can be merged into mainline. The first step on that way was to actually get your prototype running. >> >> Now I have managed to get a version of your prototype that only includes the minimal set of changes needed to support the static launcher, and that works on mac and linux/gcc. Since your prototype is based on 586396cbb55a31 from March, I am trying to merge the patch with the latest master. This worked fine for macOS, but I hit some unexpected snag on Linux which I'm currently investigating. >> >> We have only briefly touched on the spec change topic (for the naming of native libraries) during the zoom meetings. I also agree that we should get that part started now. It's unclear to me if there's any existing blocker for that. >> >> I don't think there is. It's just that someone needs to step up and do it. >> >> /Magnus