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: <b97ed754-3320-4458-aa8a-21d7ef4b23a6@openjdk.org>

Changeset: e2902a0e
Author:    iklam <ilam3388 at gmail.com>
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 <ilam3388 at gmail.com>
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: <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
Message-ID: <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>

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 <jianglizhou at google.com>
wrote:

> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou <jianglizhou at google.com>
> wrote:
> >
> > Hi Magnus,
> >
> > Thanks for looking into this from the build perspective.
> >
> > On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie
> > <magnus.ihse.bursie at oracle.com> 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: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240402/f8d7d9e5/attachment.htm>

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 <tr at openjdk.org>
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 <abhiscxk at openjdk.org>
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 <abimpoudis at openjdk.org>
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 <mbaesken at openjdk.org>
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 <sjayagond at openjdk.org>
Committer: Amit Kumar <amitkumar at openjdk.org>
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 <rkannathpari at openjdk.org>
Committer: Tejesh R <tr at openjdk.org>
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 <aivanov at openjdk.org>
Reviewed-by: aivanov, tr

! test/jdk/java/awt/print/PrinterJob/SecurityDialogTest.java

Changeset: 68170ae2
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
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 <ihse at openjdk.org>
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 <stuefe at openjdk.org>
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 <jvernee at openjdk.org>
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 <shade at openjdk.org>
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 <azvegint at openjdk.org>
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 <azvegint at openjdk.org>
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 <rrich at openjdk.org>
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 <psadhukhan at openjdk.org>
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 <honkar at openjdk.org>
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 <azvegint at openjdk.org>
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 <ayang at openjdk.org>
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 <aivanov at openjdk.org>
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 <aivanov at openjdk.org>
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 <dnguyen at openjdk.org>
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 <dnguyen at openjdk.org>
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 <prr at openjdk.org>
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 <prr at openjdk.org>
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 <dnguyen at openjdk.org>
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 <vklang at openjdk.org>
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 <prr at openjdk.org>
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 <abakhtin at openjdk.org>
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 <lmesnik at openjdk.org>
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 <prr at openjdk.org>
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 <acobbs at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
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 <honkar at openjdk.org>
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 <sspitsyn at openjdk.org>
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 <ksakata at openjdk.org>
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 <tr at openjdk.org>
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 <abhiscxk at openjdk.org>
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 <cstein at openjdk.org>
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 <pkoppula at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
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 <mbaesken at openjdk.org>
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 <gli at openjdk.org>
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 <jkern at openjdk.org>
Committer: Martin Doerr <mdoerr at openjdk.org>
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 <abhiscxk at openjdk.org>
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 <psadhukhan at openjdk.org>
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 <dnsimon at openjdk.org>
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 <abhiscxk at openjdk.org>
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 <ayang at openjdk.org>
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 <azvegint at openjdk.org>
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 <ihse at openjdk.org>
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 <shade at openjdk.org>
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 <mcimadamore at openjdk.org>
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 <mbalao at openjdk.org>
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 <kizune at openjdk.org>
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 <kizune at openjdk.org>
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 <jwilhelm at openjdk.org>
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 <nizar.benalla at oracle.com>
Committer: Justin Lu <jlu at openjdk.org>
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 <prr at openjdk.org>
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 <honkar at openjdk.org>
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 <zgu at openjdk.org>
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 <ccheung at openjdk.org>
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 <serb at openjdk.org>
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 <dnguyen at openjdk.org>
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 <amenkov at openjdk.org>
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 <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
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 <jkarthikeyan at openjdk.org>
Committer: Emanuel Peter <epeter at openjdk.org>
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 <kbarrett at openjdk.org>
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 <mbaesken at openjdk.org>
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 <rgiulietti at openjdk.org>
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 <mbaesken at openjdk.org>
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 <pminborg at openjdk.org>
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 <psadhukhan at openjdk.org>
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 <shade at openjdk.org>
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 <dlunden at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
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 <roland at openjdk.org>
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 <zgu at openjdk.org>
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 <roland at openjdk.org>
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 <ihse at openjdk.org>
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 <dnguyen at openjdk.org>
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 <rhalade at openjdk.org>
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 <clanger at openjdk.org>
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 <achung at openjdk.org>
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 <kizune at openjdk.org>
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 <shade at openjdk.org>
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 <azvegint at openjdk.org>
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 <dnguyen at openjdk.org>
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 <dnguyen at openjdk.org>
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 <kizune at openjdk.org>
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 <sspitsyn at openjdk.org>
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 <ksakata at openjdk.org>
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 <jiefu at openjdk.org>
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 <lkorinth at openjdk.org>
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 <ihse at openjdk.org>
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 <mbaesken at openjdk.org>
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 <elifasln at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
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 <gli at openjdk.org>
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 <gli at openjdk.org>
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 <mbaesken at openjdk.org>
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 <dnsimon at openjdk.org>
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 <dnguyen at openjdk.org>
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 <dfuchs at openjdk.org>
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 <amenkov at openjdk.org>
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 <stuefe at openjdk.org>
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 <abimpoudis at openjdk.org>
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 <ayang at openjdk.org>
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 <ihse at openjdk.org>
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 <hannesw at openjdk.org>
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 <ihse at openjdk.org>
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 <shade at openjdk.org>
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 <roland at openjdk.org>
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 <dnsimon at openjdk.org>
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 <achung at openjdk.org>
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 <achung at openjdk.org>
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 <jlu at openjdk.org>
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 <kvn at openjdk.org>
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 <rkennke at openjdk.org>
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 <gli at openjdk.org>
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 <ihse at openjdk.org>
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 <stuefe at openjdk.org>
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 <kevinw at openjdk.org>
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 <dnsimon at openjdk.org>
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 <kevinw at openjdk.org>
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 <eosterlund at openjdk.org>
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 <ccheung at openjdk.org>
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 <dnguyen at openjdk.org>
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 <coleenp at openjdk.org>
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 <eirbjo at openjdk.org>
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 <fbredberg at openjdk.org>
Committer: Coleen Phillimore <coleenp at openjdk.org>
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 <jlu at openjdk.org>
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 <jwaters at openjdk.org>
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 <rjolly at users.sourceforge.net>
Committer: Alexey Ivanov <aivanov at openjdk.org>
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 <gli at openjdk.org>
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 <weijun at openjdk.org>
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 <iklam at openjdk.org>
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 <naoto at openjdk.org>
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 <ccheung at openjdk.org>
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 <prr at openjdk.org>
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 <iklam at openjdk.org>
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 <simonis at openjdk.org>
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 <ihse at openjdk.org>
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 <achung at openjdk.org>
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 <psadhukhan at openjdk.org>
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 <ccheung at openjdk.org>
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 <shade at openjdk.org>
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 <shade at openjdk.org>
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 <dcubed at openjdk.org>
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 <jiefu at openjdk.org>
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 <sspitsyn at openjdk.org>
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 <jpai at openjdk.org>
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 <iklam at openjdk.org>
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 <rkannathpari at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
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 <prr at openjdk.org>
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 <apangin at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
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 <epeter at openjdk.org>
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 <kbarrett at openjdk.org>
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 <manc at openjdk.org>
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 <coffeys at openjdk.org>
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 <gli at openjdk.org>
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 <aivanov at openjdk.org>
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 <rkannathpari at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
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 <ihse at openjdk.org>
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 <ihse at openjdk.org>
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 <rkannathpari at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
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 <gli at openjdk.org>
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 <bpb at openjdk.org>
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 <coffeys at openjdk.org>
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 <honkar at openjdk.org>
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 <simonis at openjdk.org>
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 <ilam3388 at gmail.com>
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: <cd866a17-d49a-49fa-8ca9-5bcf8c053c7c@openjdk.org>

Changeset: a81c1cc9
Author:    iklam <ilam3388 at gmail.com>
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 <achung at openjdk.org>
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 <amenkov at openjdk.org>
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 <lusou.zq at alibaba-inc.com>
Committer: Vladimir Kozlov <kvn at openjdk.org>
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 <dlunden at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
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 <fyang at openjdk.org>
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 <gli at openjdk.org>
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 <stefank at openjdk.org>
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 <ayang at openjdk.org>
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 <ayang at openjdk.org>
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 <coleenp at openjdk.org>
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 <gli at openjdk.org>
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 <vromero at openjdk.org>
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 <vromero at openjdk.org>
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 <mikael at openjdk.org>
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 <darcy at openjdk.org>
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 <bhuang at openjdk.org>
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 <mdonovan at openjdk.org>
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 <tzezula at openjdk.org>
Committer: Doug Simon <dnsimon at openjdk.org>
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 <iklam at openjdk.org>
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 <gli at openjdk.org>
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 <epeter at openjdk.org>
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 <epeter at openjdk.org>
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 <chagedorn at openjdk.org>
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 <chagedorn at openjdk.org>
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 <mbaesken at openjdk.org>
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 <ayang at openjdk.org>
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 <iwalulya at openjdk.org>
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 <coleenp at openjdk.org>
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 <fbredberg at openjdk.org>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
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 <kbarrett at openjdk.org>
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 <kevinw at openjdk.org>
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 <wetmore at openjdk.org>
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 <vklang at openjdk.org>
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 <kvn at openjdk.org>
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 <vladimir.kozlov at oracle.com>
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 <ilam3388 at gmail.com>
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 <ilam3388 at gmail.com>
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 <ilam3388 at gmail.com>
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 <asmehra at redhat.com>
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 <asmehra at redhat.com>

! 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: <b168b267-9896-4bb4-8f93-5a253f27ce42@openjdk.org>

Changeset: 7ecd661f
Author:    Igor Veresov <igor.veresov at oracle.com>
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 <ilam3388 at gmail.com>
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 <asmehra at redhat.com>
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 <asmehra at redhat.com>

! 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 <ilam3388 at gmail.com>
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 <ilam3388 at gmail.com>
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 <ilam3388 at gmail.com>
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 <ilam3388 at gmail.com>
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: <CAA9v-_OQnFk-Pm71MTyYnXw=htYdkcq-MDjvoCx3N6upL6hOGA@mail.gmail.com>

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: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240411/d39dd15c/attachment.htm>

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 <ilam3388 at gmail.com>
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: <CAA9v-_OQnFk-Pm71MTyYnXw=htYdkcq-MDjvoCx3N6upL6hOGA@mail.gmail.com>
References: <CAA9v-_OQnFk-Pm71MTyYnXw=htYdkcq-MDjvoCx3N6upL6hOGA@mail.gmail.com>
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: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240412/66e6873f/attachment.htm>

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: <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
 <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
Message-ID: <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>

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_<library-name>". 
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 <jianglizhou at google.com> 
> wrote:
>
>     On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou
>     <jianglizhou at google.com> wrote:
>     >
>     > Hi Magnus,
>     >
>     > Thanks for looking into this from the build perspective.
>     >
>     > On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie
>     > <magnus.ihse.bursie at oracle.com> 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: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240412/bcb4ec99/attachment.htm>

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: <CAA9v-_OQnFk-Pm71MTyYnXw=htYdkcq-MDjvoCx3N6upL6hOGA@mail.gmail.com>
 <3c513661-d65a-4588-a83a-526b69f56d74@oracle.com>
Message-ID: <CAA9v-_OvpoQkz16xvA7O-ON78cXMm3uGMTUnyvh-6YuDYMs1mA@mail.gmail.com>

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 <Alan.Bateman at oracle.com>
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: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240414/e09df4e1/attachment.htm>

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: <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
 <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
 <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
Message-ID: <CALrW1jyLoDOtXPqfrgeqt17KyQpnSL+Z5ofLvjngKzSOwhDjDw@mail.gmail.com>

Magnus, thanks for the response. Please see comments inlined below.

On Fri, Apr 12, 2024 at 4:52?AM Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> 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_<library-name>". 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_<library-name> 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 <jianglizhou at google.com> wrote:
>>
>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou <jianglizhou at google.com> wrote:
>> >
>> > Hi Magnus,
>> >
>> > Thanks for looking into this from the build perspective.
>> >
>> > On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie
>> > <magnus.ihse.bursie at oracle.com> 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: <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
 <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
 <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
Message-ID: <CAP2b4GNMWTcQuj7Ox+qgfgyUQH9UWhKDOr_HOwQ0W05GLDsFaw@mail.gmail.com>

> 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
<magnus.ihse.bursie at oracle.com> 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_<library-name>". 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 <jianglizhou at google.com> wrote:
>>
>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou <jianglizhou at google.com> wrote:
>> >
>> > Hi Magnus,
>> >
>> > Thanks for looking into this from the build perspective.
>> >
>> > On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie
>> > <magnus.ihse.bursie at oracle.com> 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 <igor.veresov at oracle.com>
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 <igor.veresov at oracle.com>
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 <igor.veresov at oracle.com>
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 <ilam3388 at gmail.com>
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: <CALrW1jyLoDOtXPqfrgeqt17KyQpnSL+Z5ofLvjngKzSOwhDjDw@mail.gmail.com>
References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
 <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
 <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
 <CALrW1jyLoDOtXPqfrgeqt17KyQpnSL+Z5ofLvjngKzSOwhDjDw@mail.gmail.com>
Message-ID: <CA+3eh110LAFxm+DjB_fxO=WmKj3kvedr857jR8P_KdyoJzK8vg@mail.gmail.com>

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 <jianglizhou at google.com> wrote:
>
> Magnus, thanks for the response. Please see comments inlined below.
>
> On Fri, Apr 12, 2024 at 4:52?AM Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> 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_<library-name>". 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_<library-name> 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 <jianglizhou at google.com> wrote:
> >>
> >> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou <jianglizhou at google.com> wrote:
> >> >
> >> > Hi Magnus,
> >> >
> >> > Thanks for looking into this from the build perspective.
> >> >
> >> > On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie
> >> > <magnus.ihse.bursie at oracle.com> 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: <CALrW1jyLoDOtXPqfrgeqt17KyQpnSL+Z5ofLvjngKzSOwhDjDw@mail.gmail.com>
References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
 <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
 <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
 <CALrW1jyLoDOtXPqfrgeqt17KyQpnSL+Z5ofLvjngKzSOwhDjDw@mail.gmail.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_<library-name>". 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_<library-name> 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: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240416/dc85a939/attachment.htm>

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: <CA+3eh110LAFxm+DjB_fxO=WmKj3kvedr857jR8P_KdyoJzK8vg@mail.gmail.com>
References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
 <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
 <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
 <CALrW1jyLoDOtXPqfrgeqt17KyQpnSL+Z5ofLvjngKzSOwhDjDw@mail.gmail.com>
 <CA+3eh110LAFxm+DjB_fxO=WmKj3kvedr857jR8P_KdyoJzK8vg@mail.gmail.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 <jianglizhou at google.com> wrote:
>> Magnus, thanks for the response. Please see comments inlined below.
>>
>> On Fri, Apr 12, 2024 at 4:52?AM Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com> 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_<library-name>". 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_<library-name> 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 <jianglizhou at google.com> wrote:
>>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou <jianglizhou at google.com> wrote:
>>>>> Hi Magnus,
>>>>>
>>>>> Thanks for looking into this from the build perspective.
>>>>>
>>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie
>>>>> <magnus.ihse.bursie at oracle.com> 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>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
 <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
 <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
 <CALrW1jyLoDOtXPqfrgeqt17KyQpnSL+Z5ofLvjngKzSOwhDjDw@mail.gmail.com>
 <8852ba23-2830-4d23-ae52-11c554d8d750@oracle.com>
Message-ID: <CALrW1jw=VQgF37JRW7rt1K7XRAMrL+400_iJyjp+x1dwSC9nvg@mail.gmail.com>

On Tue, Apr 16, 2024 at 8:30?AM Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> 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=<jdk_path>
--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_<library-name>". 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_<library-name> 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>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
 <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
 <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
 <CALrW1jyLoDOtXPqfrgeqt17KyQpnSL+Z5ofLvjngKzSOwhDjDw@mail.gmail.com>
 <CA+3eh110LAFxm+DjB_fxO=WmKj3kvedr857jR8P_KdyoJzK8vg@mail.gmail.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 <images-dir>/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 <jianglizhou at google.com> wrote:
> > > Magnus, thanks for the response. Please see comments inlined below.
> > > 
> > > On Fri, Apr 12, 2024 at 4:52?AM Magnus Ihse Bursie
> > > <magnus.ihse.bursie at oracle.com> 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_<library-name>". 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_<library-name> 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 <jianglizhou at google.com> wrote:
> > > > > On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou <jianglizhou at google.com> wrote:
> > > > > > Hi Magnus,
> > > > > > 
> > > > > > Thanks for looking into this from the build perspective.
> > > > > > 
> > > > > > On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie
> > > > > > <magnus.ihse.bursie at oracle.com> 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>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
 <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
 <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
 <CALrW1jyLoDOtXPqfrgeqt17KyQpnSL+Z5ofLvjngKzSOwhDjDw@mail.gmail.com>
 <CA+3eh110LAFxm+DjB_fxO=WmKj3kvedr857jR8P_KdyoJzK8vg@mail.gmail.com>
 <4bda696b-eb73-497c-ac9d-b128fc887514@oracle.com>
Message-ID: <CA+3eh11qb2AsHuFPgdHpRo6i3MMmmLSb57SQ0XCe5Q65ckT-=w@mail.gmail.com>

On Tue, Apr 16, 2024 at 5:40?PM Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> 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 <jianglizhou at google.com> wrote:
> >> Magnus, thanks for the response. Please see comments inlined below.
> >>
> >> On Fri, Apr 12, 2024 at 4:52?AM Magnus Ihse Bursie
> >> <magnus.ihse.bursie at oracle.com> 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_<library-name>". 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_<library-name> 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 <jianglizhou at google.com> wrote:
> >>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou <jianglizhou at google.com> wrote:
> >>>>> Hi Magnus,
> >>>>>
> >>>>> Thanks for looking into this from the build perspective.
> >>>>>
> >>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie
> >>>>> <magnus.ihse.bursie at oracle.com> 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: <f40a3cf5-526f-4332-b165-045c833c77bf@oracle.com>

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_<libname> (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: <f40a3cf5-526f-4332-b165-045c833c77bf@oracle.com>
References: <f40a3cf5-526f-4332-b165-045c833c77bf@oracle.com>
Message-ID: <CALrW1jzwbOyz9ZArqC4o7mfG7zUUr7mTRRymgcZuhkbT_K_Ehg@mail.gmail.com>

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
<magnus.ihse.bursie at oracle.com> 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_<libname> (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: <CALrW1jw=VQgF37JRW7rt1K7XRAMrL+400_iJyjp+x1dwSC9nvg@mail.gmail.com>
References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
 <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
 <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
 <CALrW1jyLoDOtXPqfrgeqt17KyQpnSL+Z5ofLvjngKzSOwhDjDw@mail.gmail.com>
 <8852ba23-2830-4d23-ae52-11c554d8d750@oracle.com>
 <CALrW1jw=VQgF37JRW7rt1K7XRAMrL+400_iJyjp+x1dwSC9nvg@mail.gmail.com>
Message-ID: <CALrW1jx8qU7P90xAHK=23uN9pVP2tOHtGP9_dJi6N=jrHW0uqQ@mail.gmail.com>

On Tue, Apr 16, 2024 at 9:20?AM Jiangli Zhou <jianglizhou at google.com> wrote:
>
> On Tue, Apr 16, 2024 at 8:30?AM Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> 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=<jdk_path>
> --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_<library-name>". 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_<library-name> 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: <CALrW1jzwbOyz9ZArqC4o7mfG7zUUr7mTRRymgcZuhkbT_K_Ehg@mail.gmail.com>
References: <f40a3cf5-526f-4332-b165-045c833c77bf@oracle.com>
 <CALrW1jzwbOyz9ZArqC4o7mfG7zUUr7mTRRymgcZuhkbT_K_Ehg@mail.gmail.com>
Message-ID: <CALrW1jzmrcS-qRfTJgZBVztBdRkULG7SmiW4madopb+t67HcYw@mail.gmail.com>

On Tue, Apr 16, 2024 at 12:39?PM Jiangli Zhou <jianglizhou at google.com> 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
> <magnus.ihse.bursie at oracle.com> 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=<jdk_path>
--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_<libname> (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: <f35c312b-60be-425e-b576-e2cf5152daf0@openjdk.org>

Changeset: d80d4781
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
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 <amenkov at openjdk.org>
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 <mikael at openjdk.org>
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 <dholmes at openjdk.org>
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 <dholmes at openjdk.org>
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 <dholmes at openjdk.org>
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 <darcy at openjdk.org>
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 <rrich at openjdk.org>
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 <epeter at openjdk.org>
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 <chagedorn at openjdk.org>
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 <rcastanedalo at openjdk.org>
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 <pminborg at openjdk.org>
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 <stefank at openjdk.org>
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 <abimpoudis at openjdk.org>
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 <jwaters at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
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 <ihse at openjdk.org>
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 <ihse at openjdk.org>
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 <ayang at openjdk.org>
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 <gli at openjdk.org>
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 <stefank at openjdk.org>
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 <gli at openjdk.org>
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 <jpai at openjdk.org>
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 <bpb at openjdk.org>
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 <achung at openjdk.org>
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 <iklam at openjdk.org>
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 <mli at openjdk.org>
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 <jpai at openjdk.org>
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 <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
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 <djelinski at openjdk.org>
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 <thartmann at openjdk.org>
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 <stefank at openjdk.org>
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 <prappo at openjdk.org>
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 <chagedorn at openjdk.org>
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 <thartmann at openjdk.org>
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 <jlahoda at openjdk.org>
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 <abuckley at openjdk.org>
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 <mbaesken at openjdk.org>
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 <matsaave at openjdk.org>
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 <aivanov at openjdk.org>
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 <ayang at openjdk.org>
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 <gli at openjdk.org>
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 <naoto at openjdk.org>
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 <rriggs at openjdk.org>
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 <ayang at openjdk.org>
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 <ayang at openjdk.org>
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 <srinivas.vamsi.parasa at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
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 <mullan at openjdk.org>
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 <cslucas at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
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 <jbhateja at openjdk.org>
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 <dholmes at openjdk.org>
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 <aboldtch at openjdk.org>
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 <asotona at openjdk.org>
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 <jiefu at openjdk.org>
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 <asotona at openjdk.org>
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 <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
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 <asotona at openjdk.org>
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 <aivanov at openjdk.org>
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 <ayang at openjdk.org>
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 <stefank at openjdk.org>
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 <stefank at openjdk.org>
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 <stefank at openjdk.org>
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 <jpai at openjdk.org>
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 <aivanov at openjdk.org>
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 <gli at openjdk.org>
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 <djelinski at openjdk.org>
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 <ayang at openjdk.org>
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 <asotona at openjdk.org>
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 <asotona at openjdk.org>
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 <rkennke at openjdk.org>
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 <rehn at openjdk.org>
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 <rehn at openjdk.org>
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 <kvn at openjdk.org>
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 <enikitin at openjdk.org>
Committer: Paul Sandoz <psandoz at openjdk.org>
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 <kvn at openjdk.org>
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 <ben.perez at oracle.com>
Committer: Sean Mullan <mullan at openjdk.org>
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 <valeriep at openjdk.org>
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 <jpai at openjdk.org>
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 <amitkumar at openjdk.org>
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 <iklam at openjdk.org>
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 <bulasevich at openjdk.org>
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 <tr at openjdk.org>
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 <jsjolen at openjdk.org>
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 <sjayagond at openjdk.org>
Committer: Amit Kumar <amitkumar at openjdk.org>
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 <gli at openjdk.org>
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 <ayang at openjdk.org>
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 <dclarke at openjdk.org>
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 <coleenp at openjdk.org>
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 <asmehra at openjdk.org>
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 <aivanov at openjdk.org>
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 <jsjolen at openjdk.org>
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 <dclarke at openjdk.org>
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 <sspitsyn at openjdk.org>
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 <sspitsyn at openjdk.org>
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 <stuefe at openjdk.org>
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 <jbhateja at openjdk.org>
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 <roland at openjdk.org>
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 <roland at openjdk.org>
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 <mbaesken at openjdk.org>
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 <aboldtch at openjdk.org>
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 <ihse at openjdk.org>
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 <lujaniuk at openjdk.org>
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 <tschatzl at openjdk.org>
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 <djelinski at openjdk.org>
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 <coleenp at openjdk.org>
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 <mchhipa at openjdk.org>
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 <ihse at openjdk.org>
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 <gli at openjdk.org>
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 <cslucas at openjdk.org>
Committer: Martin Doerr <mdoerr at openjdk.org>
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 <ayang at openjdk.org>
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 <jvernee at openjdk.org>
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 <matsaave at openjdk.org>
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 <aboldtch at openjdk.org>
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 <roland at openjdk.org>
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 <tschatzl at openjdk.org>
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 <gli at openjdk.org>
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 <gli at openjdk.org>
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 <ayang at openjdk.org>
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 <iwalulya at openjdk.org>
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 <tr at openjdk.org>
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 <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
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 <coleenp at openjdk.org>
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 <gli at openjdk.org>
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 <gli at openjdk.org>
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 <gli at openjdk.org>
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 <mbaesken at openjdk.org>
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 <ihse at openjdk.org>
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 <amenkov at openjdk.org>
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 <sgibbons at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
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 <sspitsyn at openjdk.org>
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 <lmesnik at openjdk.org>
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 <chagedorn at openjdk.org>
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 <dholmes at openjdk.org>
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 <dholmes at openjdk.org>
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 <yzheng at openjdk.org>
Committer: Doug Simon <dnsimon at openjdk.org>
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 <jkern at openjdk.org>
Committer: Martin Doerr <mdoerr at openjdk.org>
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 <pminborg at openjdk.org>
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 <tschatzl at openjdk.org>
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 <ayang at openjdk.org>
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 <stuefe at openjdk.org>
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 <darcy at openjdk.org>
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 <darcy at openjdk.org>
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 <cao.joshua at yahoo.com>
Committer: Emanuel Peter <epeter at openjdk.org>
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 <dholmes at openjdk.org>
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 <fbredberg at openjdk.org>
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 <weijun at openjdk.org>
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 <gli at openjdk.org>
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 <mgronlun at openjdk.org>
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 <asotona at openjdk.org>
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 <kevinw at openjdk.org>
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 <vklang at openjdk.org>
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 <ayang at openjdk.org>
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 <ihse at openjdk.org>
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 <ihse at openjdk.org>
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 <pchilanomate at openjdk.org>
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 <roland at openjdk.org>
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 <aph at openjdk.org>
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 <vlivanov at openjdk.org>
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 <ilam3388 at gmail.com>
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 <igor.veresov at oracle.com>
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: <CAP2b4GNMWTcQuj7Ox+qgfgyUQH9UWhKDOr_HOwQ0W05GLDsFaw@mail.gmail.com>
References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
 <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
 <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
 <CAP2b4GNMWTcQuj7Ox+qgfgyUQH9UWhKDOr_HOwQ0W05GLDsFaw@mail.gmail.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
> <magnus.ihse.bursie at oracle.com> 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_<library-name>". 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 <jianglizhou at google.com> wrote:
>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou <jianglizhou at google.com> wrote:
>>>> Hi Magnus,
>>>>
>>>> Thanks for looking into this from the build perspective.
>>>>
>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie
>>>> <magnus.ihse.bursie at oracle.com> 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>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
 <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
 <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
 <CAP2b4GNMWTcQuj7Ox+qgfgyUQH9UWhKDOr_HOwQ0W05GLDsFaw@mail.gmail.com>
 <5b35878b-6413-4e3f-b9e3-a9b761516c99@oracle.com>
Message-ID: <CAP2b4GOO-X+5J-v1UD2EKMCiCKxAbNuWfNQks81a3HVGtjfqXA@mail.gmail.com>

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
<magnus.ihse.bursie at oracle.com> 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
> > <magnus.ihse.bursie at oracle.com> 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_<library-name>". 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 <jianglizhou at google.com> wrote:
> >>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou <jianglizhou at google.com> wrote:
> >>>> Hi Magnus,
> >>>>
> >>>> Thanks for looking into this from the build perspective.
> >>>>
> >>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie
> >>>> <magnus.ihse.bursie at oracle.com> 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 <igor.veresov at oracle.com>
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: <CAP2b4GOO-X+5J-v1UD2EKMCiCKxAbNuWfNQks81a3HVGtjfqXA@mail.gmail.com>
References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
 <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
 <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
 <CAP2b4GNMWTcQuj7Ox+qgfgyUQH9UWhKDOr_HOwQ0W05GLDsFaw@mail.gmail.com>
 <5b35878b-6413-4e3f-b9e3-a9b761516c99@oracle.com>
 <CAP2b4GOO-X+5J-v1UD2EKMCiCKxAbNuWfNQks81a3HVGtjfqXA@mail.gmail.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
> <magnus.ihse.bursie at oracle.com> 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
>>> <magnus.ihse.bursie at oracle.com> 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_<library-name>". 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 <jianglizhou at google.com> wrote:
>>>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou <jianglizhou at google.com> wrote:
>>>>>> Hi Magnus,
>>>>>>
>>>>>> Thanks for looking into this from the build perspective.
>>>>>>
>>>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie
>>>>>> <magnus.ihse.bursie at oracle.com> 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>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
 <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
 <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
 <CAP2b4GNMWTcQuj7Ox+qgfgyUQH9UWhKDOr_HOwQ0W05GLDsFaw@mail.gmail.com>
 <5b35878b-6413-4e3f-b9e3-a9b761516c99@oracle.com>
 <CAP2b4GOO-X+5J-v1UD2EKMCiCKxAbNuWfNQks81a3HVGtjfqXA@mail.gmail.com>
 <624a831e-6f5d-47dc-a2c9-3040dabb8fd4@oracle.com>
Message-ID: <CAP2b4GP92v1rBa9hYrGqoW4D2MeBPCzLXu6zGE9mo8Bfx0bQvQ@mail.gmail.com>

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=<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
<magnus.ihse.bursie at oracle.com> 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
> > <magnus.ihse.bursie at oracle.com> 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
> >>> <magnus.ihse.bursie at oracle.com> 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_<library-name>". 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 <jianglizhou at google.com> wrote:
> >>>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou <jianglizhou at google.com> wrote:
> >>>>>> Hi Magnus,
> >>>>>>
> >>>>>> Thanks for looking into this from the build perspective.
> >>>>>>
> >>>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie
> >>>>>> <magnus.ihse.bursie at oracle.com> 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: <CAP2b4GP92v1rBa9hYrGqoW4D2MeBPCzLXu6zGE9mo8Bfx0bQvQ@mail.gmail.com>
References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
 <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
 <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
 <CAP2b4GNMWTcQuj7Ox+qgfgyUQH9UWhKDOr_HOwQ0W05GLDsFaw@mail.gmail.com>
 <5b35878b-6413-4e3f-b9e3-a9b761516c99@oracle.com>
 <CAP2b4GOO-X+5J-v1UD2EKMCiCKxAbNuWfNQks81a3HVGtjfqXA@mail.gmail.com>
 <624a831e-6f5d-47dc-a2c9-3040dabb8fd4@oracle.com>
 <CAP2b4GP92v1rBa9hYrGqoW4D2MeBPCzLXu6zGE9mo8Bfx0bQvQ@mail.gmail.com>
Message-ID: <CAP2b4GMt=u_imJVFQzg_8dimWMsbLev_G4PSn37TsVvS1M7j0g@mail.gmail.com>

Oops, I meant

__declspec(dllexport) void exportedMethod() {} with braces, not brackets

On Thu, Apr 18, 2024 at 8:27?PM Julian Waters <tanksherman27 at gmail.com> 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=<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
> <magnus.ihse.bursie at oracle.com> 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
> > > <magnus.ihse.bursie at oracle.com> 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
> > >>> <magnus.ihse.bursie at oracle.com> 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_<library-name>". 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 <jianglizhou at google.com> wrote:
> > >>>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou <jianglizhou at google.com> wrote:
> > >>>>>> Hi Magnus,
> > >>>>>>
> > >>>>>> Thanks for looking into this from the build perspective.
> > >>>>>>
> > >>>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie
> > >>>>>> <magnus.ihse.bursie at oracle.com> 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>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
 <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
 <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
 <CAP2b4GNMWTcQuj7Ox+qgfgyUQH9UWhKDOr_HOwQ0W05GLDsFaw@mail.gmail.com>
 <5b35878b-6413-4e3f-b9e3-a9b761516c99@oracle.com>
 <CAP2b4GOO-X+5J-v1UD2EKMCiCKxAbNuWfNQks81a3HVGtjfqXA@mail.gmail.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>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
 <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
 <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
 <CAP2b4GNMWTcQuj7Ox+qgfgyUQH9UWhKDOr_HOwQ0W05GLDsFaw@mail.gmail.com>
 <5b35878b-6413-4e3f-b9e3-a9b761516c99@oracle.com>
 <CAP2b4GOO-X+5J-v1UD2EKMCiCKxAbNuWfNQks81a3HVGtjfqXA@mail.gmail.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>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
 <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>
 <CALrW1jx9h-nhKNV9EYnnzahPZAhYLjKtTwEaLjhjEoN7AWhicg@mail.gmail.com>
 <fc7caed9-4037-4ffc-a5d9-b6cb3e8f6295@oracle.com>
 <CAP2b4GNMWTcQuj7Ox+qgfgyUQH9UWhKDOr_HOwQ0W05GLDsFaw@mail.gmail.com>
 <5b35878b-6413-4e3f-b9e3-a9b761516c99@oracle.com>
 <CAP2b4GOO-X+5J-v1UD2EKMCiCKxAbNuWfNQks81a3HVGtjfqXA@mail.gmail.com>
 <624a831e-6f5d-47dc-a2c9-3040dabb8fd4@oracle.com>
 <5d9763e9-87a9-450e-b436-deb74d557ca8@oracle.com>
 <1a085d1a-226f-4b44-a249-4184f409d41e@oracle.com>
Message-ID: <a3778b00-050c-496c-b3a6-2bc72367fee7@oracle.com>

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: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240419/1273670a/attachment.htm>

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 <vladimir.kozlov at oracle.com>
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 <ilam3388 at gmail.com>
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 <ilam3388 at gmail.com>
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: <CALrW1jzmrcS-qRfTJgZBVztBdRkULG7SmiW4madopb+t67HcYw@mail.gmail.com>
References: <f40a3cf5-526f-4332-b165-045c833c77bf@oracle.com>
 <CALrW1jzwbOyz9ZArqC4o7mfG7zUUr7mTRRymgcZuhkbT_K_Ehg@mail.gmail.com>
 <CALrW1jzmrcS-qRfTJgZBVztBdRkULG7SmiW4madopb+t67HcYw@mail.gmail.com>
Message-ID: <d6c28a15-69e6-4e03-9258-a801b5aad092@oracle.com>

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 <ilam3388 at gmail.com>
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: <bf87feba-a5ed-4d86-9181-f401d288df75@openjdk.org>

Changeset: c40b2993
Author:    iklam <ilam3388 at gmail.com>
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: <bf22db84-a6b4-41a0-89f9-8de4b0fa9f88@openjdk.org>

Changeset: 74c0bfad
Author:    iklam <ilam3388 at gmail.com>
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: <d6c28a15-69e6-4e03-9258-a801b5aad092@oracle.com>
References: <f40a3cf5-526f-4332-b165-045c833c77bf@oracle.com>
 <CALrW1jzwbOyz9ZArqC4o7mfG7zUUr7mTRRymgcZuhkbT_K_Ehg@mail.gmail.com>
 <CALrW1jzmrcS-qRfTJgZBVztBdRkULG7SmiW4madopb+t67HcYw@mail.gmail.com>
 <d6c28a15-69e6-4e03-9258-a801b5aad092@oracle.com>
Message-ID: <CALrW1jzsJX4g-vC_sF3uk5KaO6A+sHC8NdOWcQFxUsk5wV6Swg@mail.gmail.com>

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: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240424/613a18e7/attachment.htm>

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: <cef5be7a-1983-4fbe-bd91-5d5ef1746b15@openjdk.org>

Changeset: 8571089b
Author:    iklam <ilam3388 at gmail.com>
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: <CALrW1jzsJX4g-vC_sF3uk5KaO6A+sHC8NdOWcQFxUsk5wV6Swg@mail.gmail.com>
References: <f40a3cf5-526f-4332-b165-045c833c77bf@oracle.com>
 <CALrW1jzwbOyz9ZArqC4o7mfG7zUUr7mTRRymgcZuhkbT_K_Ehg@mail.gmail.com>
 <CALrW1jzmrcS-qRfTJgZBVztBdRkULG7SmiW4madopb+t67HcYw@mail.gmail.com>
 <d6c28a15-69e6-4e03-9258-a801b5aad092@oracle.com>
 <CALrW1jzsJX4g-vC_sF3uk5KaO6A+sHC8NdOWcQFxUsk5wV6Swg@mail.gmail.com>
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: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240425/1d7380cd/attachment.htm>

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 <ilam3388 at gmail.com>
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 <ilam3388 at gmail.com>
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 <ilam3388 at gmail.com>
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: <f40a3cf5-526f-4332-b165-045c833c77bf@oracle.com>
 <CALrW1jzwbOyz9ZArqC4o7mfG7zUUr7mTRRymgcZuhkbT_K_Ehg@mail.gmail.com>
 <CALrW1jzmrcS-qRfTJgZBVztBdRkULG7SmiW4madopb+t67HcYw@mail.gmail.com>
 <d6c28a15-69e6-4e03-9258-a801b5aad092@oracle.com>
 <CALrW1jzsJX4g-vC_sF3uk5KaO6A+sHC8NdOWcQFxUsk5wV6Swg@mail.gmail.com>
 <65fdda77-1291-437e-b000-ca0307cf8084@oracle.com>
Message-ID: <CALrW1jwiQ=HOknmPehQQxc5W3mBSNfX+dzeGBaf73=g-h7hDgg@mail.gmail.com>

On Thu, Apr 25, 2024 at 9:28?AM Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> 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 <ilam3388 at gmail.com>
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: <a18486c2-4f81-4d67-a78c-222dc5becfd3@openjdk.org>

Changeset: 90df3b7f
Author:    Mark Sheppard <msheppar at openjdk.org>
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 <alanb at openjdk.org>
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 <naoto at openjdk.org>
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 <jlu at openjdk.org>
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 <egahlin at openjdk.org>
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 <ccheung at openjdk.org>
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 <valeriep at openjdk.org>
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 <amenkov at openjdk.org>
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 <never at openjdk.org>
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 <fjiang at openjdk.org>
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 <erikj at openjdk.org>
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 <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
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 <iklam at openjdk.org>
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 <amitkumar at openjdk.org>
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 <rcastanedalo at openjdk.org>
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 <syan at openjdk.org>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
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 <yzheng at openjdk.org>
Committer: Doug Simon <dnsimon at openjdk.org>
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 <pminborg at openjdk.org>
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 <djelinski at openjdk.org>
Committer: Jaikiran Pai <jaikiran.pai at gmail.com>
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 <weijun at openjdk.org>
Committer: Jaikiran Pai <jaikiran.pai at gmail.com>
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 <dholmes at openjdk.org>
Committer: Jaikiran Pai <jaikiran.pai at gmail.com>
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 <chagedorn at openjdk.org>
Committer: Jaikiran Pai <jaikiran.pai at gmail.com>
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 <chagedorn at openjdk.org>
Co-authored-by: hedongbo <hedongbo at huawei.com>
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 <jpai at openjdk.org>
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 <roland at openjdk.org>
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 <jpai at openjdk.org>
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 <ihse at openjdk.org>
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 <szaldana at openjdk.org>
Committer: Thomas Stuefe <stuefe at openjdk.org>
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 <egahlin at openjdk.org>
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 <mcimadamore at openjdk.org>
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 <acobbs at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
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 <roland at openjdk.org>
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 <pchilanomate at openjdk.org>
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 <sroy at openjdk.org>
Committer: Martin Doerr <mdoerr at openjdk.org>
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 <acobbs at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
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 <iklam at openjdk.org>
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 <asotona at openjdk.org>
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 <roysouma at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
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 <ayang at openjdk.org>
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 <mbaesken at openjdk.org>
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 <mli at openjdk.org>
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 <coleenp at openjdk.org>
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 <pminborg at openjdk.org>
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 <egahlin at openjdk.org>
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 <fyang at openjdk.org>
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 <tholenstein at openjdk.org>
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 <rkannathpari at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
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 <darcy at openjdk.org>
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 <jjg at openjdk.org>
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 <asemenyuk at openjdk.org>
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 <mbaesken at openjdk.org>
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 <hannesw at openjdk.org>
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 <rehn at openjdk.org>
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 <jpai at openjdk.org>
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 <mli at openjdk.org>
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 <abhiscxk at openjdk.org>
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 <jsjolen at openjdk.org>
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 <egahlin at openjdk.org>
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 <heidinga at openjdk.org>
Committer: Coleen Phillimore <coleenp at openjdk.org>
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 <amitkumar at openjdk.org>
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 <kvn at openjdk.org>
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 <darcy at openjdk.org>
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 <jjg at openjdk.org>
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 <darcy at openjdk.org>
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 <iklam at openjdk.org>
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 <jbhateja at openjdk.org>
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 <sgibbons at openjdk.org>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
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 <chagedorn at openjdk.org>
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 <enikitin at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
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 <gli at openjdk.org>
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 <redestad at openjdk.org>
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 <redestad at openjdk.org>
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 <gli at openjdk.org>
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 <jonas at norlinder.nu>
Committer: Erik ?sterlund <eosterlund at openjdk.org>
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 <ayang at openjdk.org>
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 <ayang at openjdk.org>
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 <coleenp at openjdk.org>
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 <coleenp at openjdk.org>
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 <ihse at openjdk.org>
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 <rkennke at openjdk.org>
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 <iklam at openjdk.org>
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 <vromero at openjdk.org>
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 <nizar.benalla at oracle.com>
Committer: Jonathan Gibbons <jjg at openjdk.org>
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 <jjg at openjdk.org>
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 <sgibbons at openjdk.org>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
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 <rcastanedalo at openjdk.org>
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 <nizar.benalla at oracle.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
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 <rcastanedalo at openjdk.org>
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 <nizar.benalla at oracle.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
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 <redestad at openjdk.org>
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 <fjiang at openjdk.org>
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 <ayang at openjdk.org>
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 <ayang at openjdk.org>
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 <asotona at openjdk.org>
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 <coleenp at openjdk.org>
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 <jbachorik at openjdk.org>
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 <ogillespie at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
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 <aivanov at openjdk.org>
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 <ayang at openjdk.org>
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 <matsaave at openjdk.org>
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 <matsaave at openjdk.org>
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 <gli at openjdk.org>
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 <alanb at openjdk.org>
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 <gli at openjdk.org>
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 <szaldana at openjdk.org>
Committer: Coleen Phillimore <coleenp at openjdk.org>
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 <avoitylov at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
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 <jjg at openjdk.org>
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 <szaldana at openjdk.org>
Committer: Coleen Phillimore <coleenp at openjdk.org>
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 <amenkov at openjdk.org>
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 <jlu at openjdk.org>
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 <sgibbons at openjdk.org>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
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 <jbhateja at openjdk.org>
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 <jkarthikeyan at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
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 <jzhu at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
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 <epeter at openjdk.org>
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 <tholenstein at openjdk.org>
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 <galder at openjdk.org>
Committer: Andrew Dinn <adinn at openjdk.org>
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 <epeter at openjdk.org>
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 <sspitsyn at openjdk.org>
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 <ayang at openjdk.org>
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 <gli at openjdk.org>
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 <sspitsyn at openjdk.org>
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 <pminborg at openjdk.org>
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 <sjohanss at openjdk.org>
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 <mbaesken at openjdk.org>
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 <ayang at openjdk.org>
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 <gziemski at openjdk.org>
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 <joshcao at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
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 <prr at openjdk.org>
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 <rkennke at openjdk.org>
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 <epeter at openjdk.org>
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 <ayang at openjdk.org>
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 <mbalao at openjdk.org>
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 <fferrari at openjdk.org>
Co-authored-by: Martin Balao <mbalao at openjdk.org>
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 <kvn at openjdk.org>
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 <jjg at openjdk.org>
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 <tr at openjdk.org>
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 <cstein at openjdk.org>
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 <clanger at openjdk.org>
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 <asotona at openjdk.org>
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 <joshcao at amazon.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
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 <asotona at openjdk.org>
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 <jlahoda at openjdk.org>
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 <gli at openjdk.org>
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 <ayang at openjdk.org>
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 <sjohanss at openjdk.org>
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 <mbaesken at openjdk.org>
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 <jkarthikeyan at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
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 <rriggs at openjdk.org>
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 <mbaesken at openjdk.org>
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 <syan at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
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 <naoto at openjdk.org>
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 <kvn at openjdk.org>
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 <ilam3388 at gmail.com>
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 <ilam3388 at gmail.com>
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 <ilam3388 at gmail.com>
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: <c24bcf78-4ded-4e13-8f59-54307f26e691@openjdk.org>

Changeset: 9076b74d
Author:    iklam <ilam3388 at gmail.com>
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: <CALrW1jwiQ=HOknmPehQQxc5W3mBSNfX+dzeGBaf73=g-h7hDgg@mail.gmail.com>
References: <f40a3cf5-526f-4332-b165-045c833c77bf@oracle.com>
 <CALrW1jzwbOyz9ZArqC4o7mfG7zUUr7mTRRymgcZuhkbT_K_Ehg@mail.gmail.com>
 <CALrW1jzmrcS-qRfTJgZBVztBdRkULG7SmiW4madopb+t67HcYw@mail.gmail.com>
 <d6c28a15-69e6-4e03-9258-a801b5aad092@oracle.com>
 <CALrW1jzsJX4g-vC_sF3uk5KaO6A+sHC8NdOWcQFxUsk5wV6Swg@mail.gmail.com>
 <65fdda77-1291-437e-b000-ca0307cf8084@oracle.com>
 <CALrW1jwiQ=HOknmPehQQxc5W3mBSNfX+dzeGBaf73=g-h7hDgg@mail.gmail.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
> <magnus.ihse.bursie at oracle.com> 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