From duke at openjdk.org  Sat May  4 23:52:58 2024
From: duke at openjdk.org (duke)
Date: Sat, 4 May 2024 23:52:58 GMT
Subject: git: openjdk/leyden: premain: 2 new changesets
Message-ID: <35e9bd39-4dd2-48a2-8789-73bf2bfb987d@openjdk.org>

Changeset: d44cdcbf
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-05-03 22:05:00 +0000
URL:       https://git.openjdk.org/leyden/commit/d44cdcbf32a2fc4fdb15e0d09b8c7f878f166481

No need to call TrainingData::restore_all_unshareable_info

! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/oops/methodData.cpp
! src/hotspot/share/oops/methodData.hpp

Changeset: 9e106c59
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-05-04 16:34:51 +0000
URL:       https://git.openjdk.org/leyden/commit/9e106c59609b42bf438c0a6bca0daa0ce1591e32

Added instructions for running Leyden-specific jtreg tests

! test/hotspot/jtreg/premain/README.md
! test/hotspot/jtreg/premain/lib/DemoSupport.gmk
+ test/hotspot/jtreg/premain/lib/build-for-jtreg.sh


From duke at openjdk.org  Mon May  6 04:30:18 2024
From: duke at openjdk.org (duke)
Date: Mon, 6 May 2024 04:30:18 GMT
Subject: git: openjdk/leyden: premain: Avoid grabbing locks inside
 MethodData::extra_data_lock
Message-ID: <65de1db6-0989-43bd-9ff5-24b6c4958df5@openjdk.org>

Changeset: eb25dca8
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-05-05 21:28:20 +0000
URL:       https://git.openjdk.org/leyden/commit/eb25dca8ab882c6ac4b95ffb171c2606fdc9bdbc

Avoid grabbing locks inside MethodData::extra_data_lock

! src/hotspot/share/oops/methodData.cpp
! src/hotspot/share/oops/methodData.hpp


From jianglizhou at google.com  Tue May  7 04:04:56 2024
From: jianglizhou at google.com (Jiangli Zhou)
Date: Mon, 6 May 2024 21:04:56 -0700
Subject: Hermetic Java project meeting
In-Reply-To: <779749fa-8427-4b48-b897-5210b36d5be8@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>
 <CALrW1jwiQ=HOknmPehQQxc5W3mBSNfX+dzeGBaf73=g-h7hDgg@mail.gmail.com>
 <779749fa-8427-4b48-b897-5210b36d5be8@oracle.com>
Message-ID: <CALrW1jzzQ8pkkXDmvM-9WbbdSiTrARZgnm6-x2V4zKC053RzgA@mail.gmail.com>

On Tue, Apr 30, 2024 at 5:42?AM Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
>
>
> 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.

The JDK and VM code has pre-existing assumptions about the JDK
directories and dynamic linking (e.g. the .so).
JLI_IsStaticJDK|JLI_SetStaticJDK|JVM_IsStaticJDK|JVM_SetStaticJDK is
needed for static JDK support to handle those cases correctly.
CreateExecutionEnvironment that I mentioned earlier is one of the
examples.

I'm quite certain the issue that you are running into is due to the
incorrect static check/handling in CreateExecutionEnvironment.

>
> 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 haven't seen your branch/code. I'd suggest not going with the #ifdef
checks as that's the opposite direction of what we want to achieve. It
doesn't seem to be worth your effort to add more #ifdef checks in
order to do static linking build work, even those are for temporary
testing reasons.

>
> 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?

In my <path>/leyden/build/linux-x86_64-server-slowdebug/images/jdk directory:

$ mv lib/jvm.cfg lib/jvm.cfg.no_used
$ find . | grep jvm.cfg
./lib/jvm.cfg.no_used

$ bin/javastatic -cp <my_jar> HelloWorld
HelloWorld

Thanks!
Jiangli
>
> /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

From magnus.ihse.bursie at oracle.com  Tue May  7 12:26:37 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 7 May 2024 14:26:37 +0200
Subject: Hermetic Java project meeting
In-Reply-To: <CALrW1jzzQ8pkkXDmvM-9WbbdSiTrARZgnm6-x2V4zKC053RzgA@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>
 <779749fa-8427-4b48-b897-5210b36d5be8@oracle.com>
 <CALrW1jzzQ8pkkXDmvM-9WbbdSiTrARZgnm6-x2V4zKC053RzgA@mail.gmail.com>
Message-ID: <6090f2aa-1480-4706-9281-035579a933af@oracle.com>

On 2024-05-07 06:04, Jiangli Zhou wrote:

> On Tue, Apr 30, 2024 at 5:42?AM Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com>  wrote:
>> 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 decided to spend the time to reinstall my machine. Now linking with 
clang works. Kind of. For some reason, it still picks up binutils ld and 
not lld, and then -l:libc++.a does not work, but when I replaced it with 
-l:libstdc++.a it worked just fine. I guess we need to either forcefully 
add -fuse-ld=lld to our clang compilation lines, or figure out if clang 
is going to call the binutils or llvm ld, and select the right option.

I still find the logic for how clang and gcc locates the default linker 
to be mostly magic. I guess I need to make a deep dive in understanding 
this to be able to resolve this properly.

> The JDK and VM code has pre-existing assumptions about the JDK
> directories and dynamic linking (e.g. the .so).
> JLI_IsStaticJDK|JLI_SetStaticJDK|JVM_IsStaticJDK|JVM_SetStaticJDK is
> needed for static JDK support to handle those cases correctly.
> CreateExecutionEnvironment that I mentioned earlier is one of the
> examples.
>
> I'm quite certain the issue that you are running into is due to the
> incorrect static check/handling in CreateExecutionEnvironment.

I'll have a look at that, thanks for the pointer.

>> 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 haven't seen your branch/code. I'd suggest not going with the #ifdef
> checks as that's the opposite direction of what we want to achieve. It
> doesn't seem to be worth your effort to add more #ifdef checks in
> order to do static linking build work, even those are for temporary
> testing reasons.

Okaaaaay... My understanding was that you wanted to push for the 
quickest possible integration of building a static java launcher into 
mainline. To do that as fast as possible, we need to use the existing 
framework for separating statically and dynamically linked libraries, 
which means doing compile time checks using #ifdefs.

Are you saying now that the priorities has changed, and that you want to 
start by introducing your framework for the runtime lookup if we are 
static or dynamic?

To be honest, I think your prototype is rather hacky in how you 
implement this, and I reckon that it will require quite a lot of work to 
be accepted into mainline. I also think you need a CSR for changing the 
Hotspot/JDK behavior wrt this, which further adds to the process.

If you want to go that route instead, then I'll put my work on hold 
until you have gotten a working solution for the runtime lookup in 
mainline. I gather this means that there is no real stress for me anymore.

/Magnus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240507/13543216/attachment.htm>

From duke at openjdk.org  Wed May  8 21:41:59 2024
From: duke at openjdk.org (duke)
Date: Wed, 8 May 2024 21:41:59 GMT
Subject: git: openjdk/leyden: premain: 159 new changesets
Message-ID: <e697d7d3-d8cd-4e2f-a424-fa6e411e97cb@openjdk.org>

Changeset: ea061298
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-04-26 07:02:45 +0000
URL:       https://git.openjdk.org/leyden/commit/ea06129851be7bd9876685f74e35392874154179

8322847: java.lang.classfile.BufWriter should specify @throws for its writeXXX methods

Reviewed-by: psandoz

! src/java.base/share/classes/java/lang/classfile/BufWriter.java

Changeset: a407dc9c
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-04-26 07:23:49 +0000
URL:       https://git.openjdk.org/leyden/commit/a407dc9cbb48c4f66af51433067925605d3bc39d

8327512: JShell does not work correctly when a class named Object or Throwable is defined

Reviewed-by: asotona

! src/jdk.jshell/share/classes/jdk/jshell/ExpressionToTypeInfo.java
! src/jdk.jshell/share/classes/jdk/jshell/KeyMap.java
! src/jdk.jshell/share/classes/jdk/jshell/SnippetMaps.java
! src/jdk.jshell/share/classes/jdk/jshell/TypePrinter.java
! src/jdk.jshell/share/classes/jdk/jshell/Wrap.java
+ test/langtools/jdk/jshell/JLCollisionTest.java

Changeset: 006f090f
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-04-26 07:50:51 +0000
URL:       https://git.openjdk.org/leyden/commit/006f090f98135e0d3b0450c455d545272cfe6a38

8331150: RISC-V: Fix "bad AD file" bug

Reviewed-by: fyang

! src/hotspot/cpu/riscv/riscv_v.ad

Changeset: 377f2e53
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-04-26 08:12:09 +0000
URL:       https://git.openjdk.org/leyden/commit/377f2e538ae0fc94fc5483700a3ae70175017741

8329862: libjli GetApplicationHome cleanups and enhance jli tracing

Reviewed-by: clanger, stuefe

! src/java.base/unix/native/libjli/java_md.c
! src/java.base/windows/native/libjli/java_md.c

Changeset: ffd850f1
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-04-26 08:26:22 +0000
URL:       https://git.openjdk.org/leyden/commit/ffd850f17efc88dddfeab629f829a03ad22dc49d

8309881: Qualified name of a type element depends on its origin (source vs class)

Reviewed-by: darcy, jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java
+ test/langtools/tools/javac/TypeToString.java

Changeset: cfd19f01
Author:    Joachim Kern <jkern at openjdk.org>
Committer: Martin Doerr <mdoerr at openjdk.org>
Date:      2024-04-26 09:26:18 +0000
URL:       https://git.openjdk.org/leyden/commit/cfd19f017681a7aded67937c5132263bbcc7be6f

8329850: [AIX] Allow loading of different members of same shared library archive

Reviewed-by: mdoerr, mbaesken, stuefe

! src/hotspot/os/aix/porting_aix.cpp

Changeset: e4ed7ced
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
Date:      2024-04-26 11:01:46 +0000
URL:       https://git.openjdk.org/leyden/commit/e4ed7ced75c53cf5ff40c5dae4830b1ee2589802

8331063: Some HttpClient tests don't report leaks

Reviewed-by: dfuchs, vtewari, michaelm

! test/jdk/java/net/httpclient/ForbiddenHeadTest.java
! test/jdk/java/net/httpclient/ProxySelectorTest.java

Changeset: 2b7176a5
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-04-26 12:06:57 +0000
URL:       https://git.openjdk.org/leyden/commit/2b7176a55ad0e5c6ba34abba3fe8fc1a411a5e2d

8330625: Compilation memory statistic: prevent tearing of the final report

Reviewed-by: kvn, thartmann

! src/hotspot/share/compiler/compilationMemoryStatistic.cpp

Changeset: 5e2ced4b
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-04-26 12:36:55 +0000
URL:       https://git.openjdk.org/leyden/commit/5e2ced4b9e1c9953e459dc152076520e5ef9d76c

8327247: C2 uses up to 2GB of RAM to compile complex string concat in extreme cases

Reviewed-by: mchung, shade

! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
! test/micro/org/openjdk/bench/java/lang/StringConcat.java

Changeset: 8bbd7251
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-04-26 14:06:53 +0000
URL:       https://git.openjdk.org/leyden/commit/8bbd7251a596c6fad1a6675c077deb9fd7c8ff95

8331187: Optimize MethodTypeDesc and ClassDesc.ofDescriptor for primitive types

Reviewed-by: jvernee, liach

! src/java.base/share/classes/java/lang/constant/ClassDesc.java
! src/java.base/share/classes/java/lang/constant/ConstantDescs.java
! src/java.base/share/classes/java/lang/constant/ConstantUtils.java
! src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java
! src/java.base/share/classes/sun/invoke/util/Wrapper.java
+ test/micro/org/openjdk/bench/java/lang/constant/ClassDescFactories.java

Changeset: d13e5334
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-04-26 14:09:29 +0000
URL:       https://git.openjdk.org/leyden/commit/d13e53346f3cd50bf7a4241ba86d2e21d9081bbe

8321014: RISC-V: C2 VectorLoadShuffle

Reviewed-by: luhenry, fyang

! src/hotspot/cpu/riscv/riscv_v.ad

Changeset: 0bf516f7
Author:    Korov <korov9 at 163.com>
Committer: Roger Riggs <rriggs at openjdk.org>
Date:      2024-04-26 14:12:49 +0000
URL:       https://git.openjdk.org/leyden/commit/0bf516f7ba8425134ca42d856648ab19f5c69a86

8330624: Inconsistent use of semicolon in the code snippet of java.io.Serializable javadoc

Reviewed-by: rriggs

! src/java.base/share/classes/java/io/Serializable.java

Changeset: 07facd04
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-04-26 17:15:09 +0000
URL:       https://git.openjdk.org/leyden/commit/07facd0420c5e51f6e85e6210644df1659fbf765

8330734: JFR: Re-engineer mirror class mechanism

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/events/DeserializationEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/ErrorThrownEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/ExceptionStatisticsEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/ExceptionThrownEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/ProcessStartEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/SecurityPropertyModificationEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/SecurityProviderServiceEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/SerializationMisdeclarationEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/SocketReadEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/SocketWriteEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/TLSHandshakeEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/ThreadSleepEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadEndEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadPinnedEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadStartEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadSubmitFailedEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/X509CertificateEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/X509ValidationEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/JVMUpcalls.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvents.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/TypeLibrary.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/util/ImplicitFields.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/util/Utils.java

Changeset: f3bb3e21
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-04-26 19:20:27 +0000
URL:       https://git.openjdk.org/leyden/commit/f3bb3e21704dd47c6c5d5753ca5882520a538c06

8331153: JFR: Improve logging of jdk/jfr/api/consumer/filestream/TestOrdered.java

Reviewed-by: mgronlun

! test/jdk/jdk/jfr/api/consumer/filestream/TestOrdered.java

Changeset: a920af23
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2024-04-26 19:47:06 +0000
URL:       https://git.openjdk.org/leyden/commit/a920af233a11592af113f456f7608cb59dd1617e

8303689: javac -Xlint could/should report on "dangling" doc comments

Reviewed-by: vromero, ihse, prr

! make/CompileDemos.gmk
! make/CompileToolsJdk.gmk
! make/GenerateLinkOptData.gmk
! make/modules/java.desktop/Java.gmk
! make/modules/java.management/Java.gmk
! make/modules/java.naming/Java.gmk
! make/modules/java.security.jgss/Java.gmk
! make/modules/java.security.sasl/Java.gmk
! make/modules/java.sql.rowset/Java.gmk
! make/modules/java.sql/Java.gmk
! make/modules/java.xml.crypto/Java.gmk
! make/modules/java.xml/Java.gmk
= make/modules/jdk.accessibility/Java.gmk
= make/modules/jdk.crypto.cryptoki/Java.gmk
! make/modules/jdk.hotspot.agent/Java.gmk
! make/modules/jdk.internal.le/Java.gmk
! make/modules/jdk.internal.vm.ci/Java.gmk
! make/modules/jdk.jdi/Java.gmk
! make/modules/jdk.jfr/Java.gmk
= make/modules/jdk.security.auth/Java.gmk
= make/modules/jdk.zipfs/Java.gmk
! make/test/BuildTestLib.gmk
! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.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/TypeEnter.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/parser/Lexer.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/ParserFactory.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Scanner.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/VirtualParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java
! src/jdk.compiler/share/classes/module-info.java
! src/jdk.compiler/share/man/javac.1
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocMemberEnter.java
! src/jdk.javadoc/share/man/javadoc.1
! test/langtools/tools/javac/OverrideChecks/6199153/T6199153.java
+ test/langtools/tools/javac/danglingDocComments/DanglingDocCommentsClass.enabled.out
+ test/langtools/tools/javac/danglingDocComments/DanglingDocCommentsClass.java
+ test/langtools/tools/javac/danglingDocComments/DanglingDocCommentsEnum.enabled.out
+ test/langtools/tools/javac/danglingDocComments/DanglingDocCommentsEnum.java
= test/langtools/tools/javac/danglingDocComments/empty.out
! test/langtools/tools/javac/depDocComment/DeprecatedDocComment3.java
+ test/langtools/tools/javac/diags/examples/DanglingDocCommentWarning/DanglingDocCommentWarning.java
! test/langtools/tools/javac/platform/PreviewAPIsWithRelease.java
! test/langtools/tools/javac/warnings/DepAnn.java
! test/langtools/tools/javac/warnings/Deprecation.java
! test/langtools/tools/javac/warnings/NestedDeprecation/NestedDeprecation.java
! test/langtools/tools/javac/warnings/Unchecked.java
! test/langtools/tools/javac/warnings/VerifyLintDescriptions.java
! test/langtools/tools/javac/warnings/suppress/T6480588.java

Changeset: aee91fbc
Author:    Hannes Walln?fer <hannesw at openjdk.org>
Date:      2024-04-26 19:59:57 +0000
URL:       https://git.openjdk.org/leyden/commit/aee91fbc70df716b96c202511b4ff1b302df8d60

8296175: Output warning if generated docs contain diagnostic markers

Reviewed-by: jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Messages.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
! test/langtools/jdk/javadoc/tool/doclint/DocLintTest.java

Changeset: aa2edd49
Author:    Jin Kwon <onacit at gmail.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
Date:      2024-04-27 01:11:33 +0000
URL:       https://git.openjdk.org/leyden/commit/aa2edd491345cca1d8798848d71b151bc06c6c02

8330686: Fix typos in the DatabaseMetaData javadoc

Reviewed-by: jpai, lancea, iris

! src/java.sql/share/classes/java/sql/DatabaseMetaData.java

Changeset: e3eb652c
Author:    Viktor Klang <vklang at openjdk.org>
Date:      2024-04-27 11:52:05 +0000
URL:       https://git.openjdk.org/leyden/commit/e3eb652c251e8298c9df95d7ed2788f2cbb5f337

8296543: Update exception documentation for ExecutorService.invokeAll overriders as required

Reviewed-by: prappo, alanb

! src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java

Changeset: a078b5e6
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-04-27 12:12:51 +0000
URL:       https://git.openjdk.org/leyden/commit/a078b5e6117d2a99386fecd349eb0e0c11b74953

8331114: Further improve performance of MethodTypeDesc::descriptorString

Reviewed-by: mchung, liach

! src/java.base/share/classes/java/lang/constant/ClassDesc.java
! src/java.base/share/classes/java/lang/constant/ConstantUtils.java
! src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java
! src/java.base/share/classes/sun/invoke/util/Wrapper.java
! test/micro/org/openjdk/bench/java/lang/constant/MethodTypeDescFactories.java

Changeset: c3372c45
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-04-27 12:13:53 +0000
URL:       https://git.openjdk.org/leyden/commit/c3372c455542cef2aaf673d1f14be8759bb98e8d

8331134: Port SimpleStringBuilderStrategy to use ClassFile API

Reviewed-by: mchung

! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
! test/micro/org/openjdk/bench/java/lang/StringConcat.java

Changeset: 16c7dcdb
Author:    Christoph Langer <clanger at openjdk.org>
Date:      2024-04-27 13:10:40 +0000
URL:       https://git.openjdk.org/leyden/commit/16c7dcdb04a7c220684a20eb4a0da4505ae03813

8330523: Reduce runtime and improve efficiency of KeepAliveTest

Reviewed-by: djelinski

! test/jdk/sun/net/www/http/HttpClient/KeepAliveTest.java

Changeset: 4e5c25ee
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-04-28 22:55:44 +0000
URL:       https://git.openjdk.org/leyden/commit/4e5c25ee43d4ec31ed5160fd93a2fd15e35182f8

8331108: Unused Math.abs call in java.lang.FdLibm.Expm1#compute

Reviewed-by: naoto, bpb, rgiulietti

! src/java.base/share/classes/java/lang/FdLibm.java

Changeset: fb63cbad
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-04-29 07:12:46 +0000
URL:       https://git.openjdk.org/leyden/commit/fb63cbadb419f1de91acae9fc66be258e1d3d214

8330684: ClassFile API runs into StackOverflowError while parsing certain class' bytes

Reviewed-by: psandoz

! src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java
! test/jdk/jdk/classfile/LimitsTest.java

Changeset: c615c18e
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2024-04-29 07:36:14 +0000
URL:       https://git.openjdk.org/leyden/commit/c615c18e9f92dc9fdc2db512fbd47fd255f7fe86

8330158: C2: Loop strip mining uses ABS with min int

Reviewed-by: shade, kvn, dlong, mbalao

! src/hotspot/share/opto/loopnode.cpp

Changeset: 4edac349
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-04-29 07:58:18 +0000
URL:       https://git.openjdk.org/leyden/commit/4edac349a5d695ce7923344ad5ad0400842241eb

8331167: UBSan enabled build fails in adlc on macOS

Reviewed-by: stuefe, lucy

! src/hotspot/share/adlc/adlparse.cpp

Changeset: 766d0b0f
Author:    Guoxiong Li <gli at openjdk.org>
Date:      2024-04-29 08:16:12 +0000
URL:       https://git.openjdk.org/leyden/commit/766d0b0fa0809a0bf500f1883592f5074482f168

8330960: Serial: Remove SerialFullGC::_total_invocations

Reviewed-by: ayang, tschatzl

! src/hotspot/share/gc/serial/serialFullGC.cpp
! src/hotspot/share/gc/serial/serialFullGC.hpp

Changeset: 76cda7b8
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-04-29 08:41:49 +0000
URL:       https://git.openjdk.org/leyden/commit/76cda7b8955b934716136092e25de19b3b4dc6c3

8331118: Remove Serial includes from space.hpp

Reviewed-by: gli, tschatzl

! src/hotspot/share/gc/epsilon/epsilonMemoryPool.cpp
! src/hotspot/share/gc/serial/tenuredGeneration.hpp
! src/hotspot/share/gc/serial/tenuredGeneration.inline.hpp
! src/hotspot/share/gc/shared/space.hpp

Changeset: 549bc6a0
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
Date:      2024-04-29 08:41:59 +0000
URL:       https://git.openjdk.org/leyden/commit/549bc6a0398906df3cc08679c751eb0c633ef0be

8330685: ZGC: share barrier spilling logic

Reviewed-by: eosterlund, mdoerr, fyang, aboldtch

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/register_aarch64.hpp
! src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp
! src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.hpp
! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp
! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.hpp
! src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.cpp
! src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.hpp
! src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp
! src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.hpp
! src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.cpp
! src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.hpp
! src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
! src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.hpp
! src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp
! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.hpp
! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp
! src/hotspot/share/gc/shared/c2/barrierSetC2.hpp
! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
! src/hotspot/share/gc/z/c2/zBarrierSetC2.hpp

Changeset: 70d3f22b
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-04-29 08:42:09 +0000
URL:       https://git.openjdk.org/leyden/commit/70d3f22b70521011027748f8cd078bd2ab9be730

8331175: Parallel: Remove VerifyRememberedSets

Reviewed-by: tschatzl, gli

! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
! src/hotspot/share/gc/parallel/psScavenge.cpp
! src/hotspot/share/gc/shared/gc_globals.hpp
! test/hotspot/jtreg/gc/g1/TestVerificationInConcurrentCycle.java

Changeset: 72729390
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-04-29 08:43:12 +0000
URL:       https://git.openjdk.org/leyden/commit/727293906430cfd95c0e2b2bd7a9df658f6fe94d

8331200: Serial: Remove unused methods in SerialHeap

Reviewed-by: gli, tschatzl

! src/hotspot/share/gc/serial/serialHeap.hpp

Changeset: 151ef5d4
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-04-29 10:58:07 +0000
URL:       https://git.openjdk.org/leyden/commit/151ef5d4d261c9fc740d3ccd64a70d3b9ccc1ab5

8330677: Add Per-Compilation memory usage to JFR

Reviewed-by: kvn, mbaesken

! src/hotspot/share/compiler/compilationMemoryStatistic.cpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/compiler/compileTask.cpp
! src/hotspot/share/compiler/compileTask.hpp
! src/hotspot/share/compiler/compilerEvent.cpp
! src/hotspot/share/compiler/compilerEvent.hpp
! src/hotspot/share/jfr/metadata/metadata.xml
! test/jdk/jdk/jfr/event/compiler/TestCompilerCompile.java

Changeset: 8b8fb642
Author:    Liming Liu <limingliu at os.amperecomputing.com>
Committer: Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-04-29 15:14:37 +0000
URL:       https://git.openjdk.org/leyden/commit/8b8fb6427e3cbc16b818ddcbd6a971f3d2370f94

8324776: runtime/os/TestTransparentHugePageUsage.java fails with The usage of THP is not enough

Reviewed-by: stuefe

! test/hotspot/jtreg/ProblemList.txt
- test/hotspot/jtreg/runtime/os/TestTransparentHugePageUsage.java

Changeset: bdcc2400
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-04-29 15:58:03 +0000
URL:       https://git.openjdk.org/leyden/commit/bdcc2400db63e604d76f9b5bd3c876271743f69f

8331087: Move immutable nmethod data from CodeCache

Reviewed-by: thartmann, dlong, dnsimon

! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/code/nmethod.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java
! test/hotspot/jtreg/compiler/c1/TestLinearScanOrderMain.java

Changeset: 4e422943
Author:    Harshitha Onkar <honkar at openjdk.org>
Date:      2024-04-29 16:27:54 +0000
URL:       https://git.openjdk.org/leyden/commit/4e4229438ad2e8ac59ac675465e4d3d4e13bf156

8329004: Update Libpng to 1.6.43

Reviewed-by: prr, dnguyen

! src/java.desktop/share/legal/libpng.md
! src/java.desktop/share/native/libsplashscreen/libpng/CHANGES
! src/java.desktop/share/native/libsplashscreen/libpng/LICENSE
! src/java.desktop/share/native/libsplashscreen/libpng/README
! src/java.desktop/share/native/libsplashscreen/libpng/UPDATING.txt
! src/java.desktop/share/native/libsplashscreen/libpng/png.c
! src/java.desktop/share/native/libsplashscreen/libpng/png.h
! src/java.desktop/share/native/libsplashscreen/libpng/pngconf.h
! src/java.desktop/share/native/libsplashscreen/libpng/pngerror.c
! src/java.desktop/share/native/libsplashscreen/libpng/pngget.c
! src/java.desktop/share/native/libsplashscreen/libpng/pnglibconf.h
! src/java.desktop/share/native/libsplashscreen/libpng/pngpread.c
! src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h
! src/java.desktop/share/native/libsplashscreen/libpng/pngread.c
! src/java.desktop/share/native/libsplashscreen/libpng/pngrtran.c
! src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c
! src/java.desktop/share/native/libsplashscreen/libpng/pngset.c
! src/java.desktop/share/native/libsplashscreen/libpng/pngtrans.c

Changeset: 9b423a85
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2024-04-29 17:14:09 +0000
URL:       https://git.openjdk.org/leyden/commit/9b423a8509d6bf8a76297d74aaaea40613f5f2ae

8330253: Remove verify_consistent_lock_order

Co-authored-by: Patricio Chilano Mateo <pchilanomate at openjdk.org>
Reviewed-by: dcubed, pchilanomate, dnsimon

! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/lockStack.cpp
! src/hotspot/share/runtime/lockStack.hpp

Changeset: eb88343f
Author:    SendaoYan <syan at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-04-29 17:50:39 +0000
URL:       https://git.openjdk.org/leyden/commit/eb88343fb763ee89010b7a9879638152decc6892

8331164: createJMHBundle.sh download jars fail when url needed to be redirected

Reviewed-by: erikj, shade

! make/devkit/createJMHBundle.sh

Changeset: 819f3d6f
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-04-29 17:54:13 +0000
URL:       https://git.openjdk.org/leyden/commit/819f3d6fc70ff6fe54ac5f9033c17c3dd4326aa5

8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier

Reviewed-by: alanb

! src/java.base/share/classes/java/io/ByteArrayOutputStream.java
+ test/jdk/java/io/ByteArrayOutputStream/WriteToReleasesCarrier.java

Changeset: b128bd7b
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-04-30 06:53:16 +0000
URL:       https://git.openjdk.org/leyden/commit/b128bd7b5a1dcf3e7a55d3e3b0c4a9998bde963e

8331021: Deprecate and then obsolete the DontYieldALot flag

Reviewed-by: coleenp, stuefe, shade

! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/globals.hpp
! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java

Changeset: 60b61e58
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-04-30 07:31:29 +0000
URL:       https://git.openjdk.org/leyden/commit/60b61e588c1252b4b1fbc64d0f818a85670f7146

8331298: avoid alignment checks in UBSAN enabled build

Reviewed-by: erikj, mdoerr

! make/autoconf/jdk-options.m4

Changeset: 0630bb02
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-04-30 08:27:38 +0000
URL:       https://git.openjdk.org/leyden/commit/0630bb02eb760081ddd612ccb1b12d57d43aab5e

8331264: Reduce java.lang.constant initialization overhead

Reviewed-by: liach, mchung

! src/java.base/share/classes/java/lang/constant/ClassDesc.java
! src/java.base/share/classes/java/lang/constant/ConstantDescs.java
! src/java.base/share/classes/java/lang/constant/ConstantUtils.java
! src/java.base/share/classes/java/lang/constant/DirectMethodHandleDescImpl.java
! src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java
! src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java
! src/java.base/share/classes/java/lang/constant/ReferenceClassDescImpl.java

Changeset: cff841f1
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-04-30 09:13:12 +0000
URL:       https://git.openjdk.org/leyden/commit/cff841f1de41c911ec1b642b998c074e13e75554

8328934: Assert that ABS input and output are legal

Reviewed-by: aph, dlong

! src/hotspot/share/utilities/globalDefinitions.hpp
+ test/hotspot/gtest/utilities/test_abs.cpp

Changeset: ef4ec2d3
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-04-30 10:37:33 +0000
URL:       https://git.openjdk.org/leyden/commit/ef4ec2d3b061c0eeea1aba88135e8d0e272b3bea

8331284: Inline methods in softRefPolicy.cpp

Reviewed-by: gli, tschatzl

- src/hotspot/share/gc/shared/softRefPolicy.cpp
! src/hotspot/share/gc/shared/softRefPolicy.hpp

Changeset: 22a1c617
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
Date:      2024-04-30 13:08:35 +0000
URL:       https://git.openjdk.org/leyden/commit/22a1c617dbe771d8f5cea52af0e2a630af34b35b

8330817: jdk/internal/vm/Continuation/OSRTest.java times out on libgraal

Reviewed-by: dnsimon, dlong

! test/jdk/jdk/internal/vm/Continuation/OSRTest.java

Changeset: 33e81229
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-04-30 13:52:08 +0000
URL:       https://git.openjdk.org/leyden/commit/33e81229bd1b4b28cf2e35f0f8f0a42a04d59c3d

8331410: Remove unused MemAllocator::mem_allocate_inside_tlab

Reviewed-by: tschatzl, gli

! src/hotspot/share/gc/shared/memAllocator.cpp
! src/hotspot/share/gc/shared/memAllocator.hpp

Changeset: 2cc8eccb
Author:    Viktor Klang <vklang at openjdk.org>
Date:      2024-04-30 15:11:04 +0000
URL:       https://git.openjdk.org/leyden/commit/2cc8eccb360848f3ddf3259f1d943552f86234b9

8331346: Update PreviewFeature of STREAM_GATHERERS to JEP-473

Reviewed-by: pminborg, alanb

! src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java

Changeset: f4caac8d
Author:    Tim Prinzing <tprinzing at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
Date:      2024-04-30 15:39:23 +0000
URL:       https://git.openjdk.org/leyden/commit/f4caac8dea1c95234743712386cb28a1ecb11197

8329138: Convert JFR FileForceEvent to static mirror event

Reviewed-by: alanb, egahlin

+ src/java.base/share/classes/jdk/internal/event/FileForceEvent.java
! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java
! src/java.base/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java
! src/java.base/unix/classes/sun/nio/fs/UnixChannelFactory.java
! src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
! src/java.base/windows/classes/sun/nio/fs/WindowsChannelFactory.java
! src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java
! src/jdk.jfr/share/classes/jdk/jfr/events/FileForceEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvents.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/FileChannelImplInstrumentor.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java
+ test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java

Changeset: 130f71ca
Author:    Evgeny Nikitin <enikitin at openjdk.org>
Committer: Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-04-30 15:48:09 +0000
URL:       https://git.openjdk.org/leyden/commit/130f71cadca5b46d9bf589708dcea03ad51e8de0

8326742: Change compiler tests without additional VM flags from @run driver to @run main

Reviewed-by: kvn, thartmann, chagedorn

! test/hotspot/jtreg/compiler/ccp/TestShiftConvertAndNotification.java

Changeset: 9ce21d13
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-04-30 16:02:55 +0000
URL:       https://git.openjdk.org/leyden/commit/9ce21d1382a4f5ad601a7ee610bab64a9c575302

8327647: Occasional SIGSEGV in markWord::displaced_mark_helper() for SPECjvm2008 sunflow

Reviewed-by: coleenp, fyang, dlong

! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
! src/hotspot/cpu/riscv/interp_masm_riscv.cpp
! src/hotspot/cpu/riscv/templateTable_riscv.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp

Changeset: 3d11692b
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-04-30 16:15:07 +0000
URL:       https://git.openjdk.org/leyden/commit/3d11692bf369af951867209962e8bf5886d1655f

8331252: C2: MergeStores: handle negative shift values

Reviewed-by: kvn, shade

! src/hotspot/share/opto/memnode.cpp
! test/hotspot/jtreg/compiler/c2/TestMergeStores.java

Changeset: aca1e836
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2024-04-30 16:20:10 +0000
URL:       https://git.openjdk.org/leyden/commit/aca1e8365bf0f64bf18caf798bbca1d25b3c4117

8329223: Parallel: Parallel GC resizes heap even if -Xms = -Xmx

Reviewed-by: ayang, gli

! src/hotspot/share/gc/shared/genArguments.cpp

Changeset: a863ef5d
Author:    Justin Lu <jlu at openjdk.org>
Date:      2024-04-30 16:50:01 +0000
URL:       https://git.openjdk.org/leyden/commit/a863ef5d74e9001a143af4638422348ee946c939

8331207: Misleading example in DateFormat#parse docs

Reviewed-by: naoto

! src/java.base/share/classes/java/text/DateFormat.java

Changeset: b96b38c2
Author:    Tom Rodriguez <never at openjdk.org>
Date:      2024-04-30 17:33:23 +0000
URL:       https://git.openjdk.org/leyden/commit/b96b38c2c9a310d5fe49b2eda3e113a71223c7d1

8318682: SA decoding of scalar replaced objects is broken

Reviewed-by: cjplummer, cslucas

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/asm/Disassembler.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java
+ src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/MarkerValue.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java
+ src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/ObjectMergeValue.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/ObjectValue.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/ScopeValue.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstMethod.java
! test/hotspot/jtreg/ProblemList-generational-zgc.txt
! test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java
+ test/hotspot/jtreg/serviceability/sa/ClhsdbTestAllocationMerge.java
+ test/hotspot/jtreg/serviceability/sa/LingeredAppWithAllocationMerge.java
+ test/hotspot/jtreg/serviceability/sa/TestDebugInfoDecode.java

Changeset: f215899a
Author:    Robbin Ehn <rehn at openjdk.org>
Date:      2024-05-01 08:09:53 +0000
URL:       https://git.openjdk.org/leyden/commit/f215899a088d1abe86adccf0e65a073189272ddd

8331393: AArch64: u32 _partial_subtype_ctr loaded/stored as 64

Reviewed-by: aph, fyang

! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp

Changeset: 663acd2e
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2024-05-01 08:40:48 +0000
URL:       https://git.openjdk.org/leyden/commit/663acd2e173114fec7c2f50084af9ec56150d394

8330969: scalability issue with loaded JVMTI agent

Reviewed-by: amenkov, cjplummer

! src/hotspot/share/prims/jvmtiEnvBase.cpp
! src/hotspot/share/prims/jvmtiThreadState.cpp
! src/hotspot/share/prims/jvmtiThreadState.hpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp

Changeset: b2fb5ea1
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-05-01 11:53:28 +0000
URL:       https://git.openjdk.org/leyden/commit/b2fb5ea13ba5087411410519213fc953ecc44618

8331142: Add test for number of loader threads in BasicDirectoryModel

Reviewed-by: serb, tr

+ test/jdk/javax/swing/plaf/basic/BasicDirectoryModel/LoaderThreadCount.java

Changeset: 44dc8500
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-05-01 12:19:11 +0000
URL:       https://git.openjdk.org/leyden/commit/44dc85001d8c17a12efebd1a69d52e0b7e4e95e4

8331212: Error recovery for broken switch expressions could be improved

Reviewed-by: asotona

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
+ test/langtools/tools/javac/recovery/FlowRecovery.java

Changeset: 4f529f8c
Author:    Pavel Rappo <prappo at openjdk.org>
Date:      2024-05-01 12:23:13 +0000
URL:       https://git.openjdk.org/leyden/commit/4f529f8c232b4082aa4aa39766bcf42b09885ee4

8331427: Rename confusingly named ArraysSupport.signedHashCode

Reviewed-by: redestad

! src/java.base/share/classes/jdk/internal/util/ArraysSupport.java

Changeset: e833bfc8
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2024-05-01 15:26:57 +0000
URL:       https://git.openjdk.org/leyden/commit/e833bfc8ac6104522d037e7eb300f5aa112688bb

8331222: Malformed text in the jpackage doc page

Reviewed-by: almatvee

! src/jdk.jpackage/share/man/jpackage.1

Changeset: 2a95cd47
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-05-01 16:38:25 +0000
URL:       https://git.openjdk.org/leyden/commit/2a95cd473aaefcacd976d1c17aa2badf330a6c32

8331495: Limit BasicDirectoryModel/LoaderThreadCount.java to Windows only

Reviewed-by: prr

! test/jdk/javax/swing/plaf/basic/BasicDirectoryModel/LoaderThreadCount.java

Changeset: 62d5d1e9
Author:    Jan Trukenm?ller <truj at users.noreply.github.com>
Committer: Phil Race <prr at openjdk.org>
Date:      2024-05-01 16:45:42 +0000
URL:       https://git.openjdk.org/leyden/commit/62d5d1e99c118b6ed26e79a2f7247308f8c23310

8319598: SMFParser misinterprets interrupted running status

Reviewed-by: prr, serb

! src/java.desktop/share/classes/com/sun/media/sound/StandardMidiFileReader.java
+ test/jdk/javax/sound/midi/File/SMFInterruptedRunningStatus.java

Changeset: 0a24daec
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2024-05-01 18:02:47 +0000
URL:       https://git.openjdk.org/leyden/commit/0a24daecebd90eb46a813923bb2d5672514197ce

8322043: HeapDumper should use parallel dump by default

Reviewed-by: yyang, sspitsyn, dholmes

! src/hotspot/share/services/attachListener.cpp
! src/hotspot/share/services/heapDumper.cpp
! src/hotspot/share/services/heapDumper.hpp

Changeset: 19e46eed
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
Committer: Dean Long <dlong at openjdk.org>
Date:      2024-05-02 01:41:09 +0000
URL:       https://git.openjdk.org/leyden/commit/19e46eed580339a61fd1309c2cc7040e8c83597d

8331088: Incorrect TraceLoopPredicate output

Reviewed-by: chagedorn, dlong

! src/hotspot/share/opto/loopPredicate.cpp

Changeset: 5ab8713b
Author:    Robbin Ehn <rehn at openjdk.org>
Date:      2024-05-02 06:29:46 +0000
URL:       https://git.openjdk.org/leyden/commit/5ab8713b3fcdf8a1e9d44fc71190845f32449fce

8331360: RISCV: u32 _partial_subtype_ctr loaded/stored as 64

Reviewed-by: fyang, mli, tonyp

! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp

Changeset: 9108091f
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-05-02 07:06:25 +0000
URL:       https://git.openjdk.org/leyden/commit/9108091f0ce21a52c3b8b22a52485ee5594eb185

8330989: unify os::create_binary_file across platforms

Reviewed-by: dholmes, kbarrett

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/runtime/os.cpp

Changeset: 4036d7d8
Author:    Afshin Zafari <azafari at openjdk.org>
Date:      2024-05-02 07:19:56 +0000
URL:       https://git.openjdk.org/leyden/commit/4036d7d8246da0550adf8543848606c777da20a1

8330076: NMT: add/make a mandatory MEMFLAGS argument to family of os::reserve/commit/uncommit memory API

Reviewed-by: stefank, jsjolen, stuefe

! src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp
! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/bsd/gc/x/xPhysicalMemoryBacking_bsd.cpp
! src/hotspot/os/bsd/gc/z/zPhysicalMemoryBacking_bsd.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/os/posix/perfMemory_posix.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/os/windows/perfMemory_windows.cpp
! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/classfile/compactHashtable.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1PageBasedVirtualSpace.cpp
! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp
! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp
! src/hotspot/share/gc/parallel/mutableSpace.cpp
! src/hotspot/share/gc/parallel/objectStartArray.cpp
! src/hotspot/share/gc/parallel/parMarkBitMap.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/parallel/psVirtualspace.cpp
! src/hotspot/share/gc/serial/serialBlockOffsetTable.cpp
! src/hotspot/share/gc/shared/cardTable.cpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/x/xMarkStackAllocator.cpp
! src/hotspot/share/gc/x/xPhysicalMemory.cpp
! src/hotspot/share/gc/x/xVirtualMemory.cpp
! src/hotspot/share/gc/z/zMarkStackAllocator.cpp
! src/hotspot/share/gc/z/zNMT.cpp
! src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp
! src/hotspot/share/memory/allocation.inline.hpp
! src/hotspot/share/memory/heap.cpp
! src/hotspot/share/memory/metaspace.cpp
! src/hotspot/share/memory/metaspace/testHelpers.cpp
! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp
! src/hotspot/share/memory/virtualspace.cpp
! src/hotspot/share/memory/virtualspace.hpp
! src/hotspot/share/nmt/memTracker.hpp
! src/hotspot/share/nmt/virtualMemoryTracker.cpp
! src/hotspot/share/nmt/virtualMemoryTracker.hpp
! src/hotspot/share/oops/compressedKlass.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! src/hotspot/share/runtime/safepointMechanism.cpp
! src/hotspot/share/utilities/debug.cpp
! test/hotspot/gtest/gc/g1/test_freeRegionList.cpp
! test/hotspot/gtest/gc/g1/test_stressCommitUncommit.cpp
! test/hotspot/gtest/gc/z/test_zForwarding.cpp
! test/hotspot/gtest/memory/test_virtualspace.cpp
! test/hotspot/gtest/nmt/test_nmt_locationprinting.cpp
! test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp
! test/hotspot/gtest/runtime/test_os.cpp
! test/hotspot/gtest/runtime/test_os_linux.cpp
! test/hotspot/gtest/runtime/test_os_reserve_between.cpp
! test/hotspot/gtest/runtime/test_os_windows.cpp
! test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp

Changeset: d3bf5262
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2024-05-02 07:49:12 +0000
URL:       https://git.openjdk.org/leyden/commit/d3bf52628efb79e1b98749d628c4b6d035e1d511

8331518: Tests should not use the "Classpath" exception form of the legal header

Reviewed-by: dholmes

! test/hotspot/jtreg/compiler/c2/TestUninitializedKlassField.java
! test/hotspot/jtreg/compiler/codegen/TestConvertImplicitNullCheck.java
! test/hotspot/jtreg/compiler/loopopts/TestPartialPeelingAtSingleInputRegion.java
! test/micro/org/openjdk/bench/java/lang/foreign/libToJavaString.c
! test/micro/org/openjdk/bench/vm/compiler/MergeStores.java

Changeset: dd906ffd
Author:    Robbin Ehn <rehn at openjdk.org>
Date:      2024-05-02 08:10:59 +0000
URL:       https://git.openjdk.org/leyden/commit/dd906ffdcb7d965cd4798cb7eebd9c1b71b3c136

8331399: RISC-V: Don't us mv instead of la

Reviewed-by: fyang, mli, tonyp

! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp

Changeset: c4fe5bf9
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-05-02 08:26:09 +0000
URL:       https://git.openjdk.org/leyden/commit/c4fe5bf90c2d368c29714de63a90eca444fb3ece

8331405: Shenandoah: Optimize ShenandoahLock with TTAS

Reviewed-by: zgu, ysr

! src/hotspot/share/gc/shenandoah/shenandoahLock.cpp

Changeset: 8bcd2e61
Author:    Erik ?sterlund <eosterlund at openjdk.org>
Date:      2024-05-02 08:31:49 +0000
URL:       https://git.openjdk.org/leyden/commit/8bcd2e61aec51f7c5b09ae162f8cca85a8bbf105

8329088: Stack chunk thawing races with concurrent GC stack iteration

Reviewed-by: stefank, pchilanomate

! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/oops/instanceStackChunkKlass.cpp
! src/hotspot/share/oops/oop.hpp
! src/hotspot/share/oops/oop.inline.hpp
! src/hotspot/share/oops/stackChunkOop.cpp
! src/hotspot/share/oops/stackChunkOop.hpp
! src/hotspot/share/oops/stackChunkOop.inline.hpp
! src/hotspot/share/runtime/continuationFreezeThaw.cpp
! src/hotspot/share/runtime/continuationJavaClasses.cpp
! src/hotspot/share/runtime/continuationJavaClasses.hpp
! src/hotspot/share/runtime/continuationJavaClasses.inline.hpp
! src/java.base/share/classes/jdk/internal/vm/StackChunk.java

Changeset: 33243d44
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2024-05-02 08:42:38 +0000
URL:       https://git.openjdk.org/leyden/commit/33243d44a96bf47066e19bb743c076cbd4ba48ed

8331394: G1: Remove SKIP_RETIRED_FULL_REGIONS define in G1HRPrinter

Reviewed-by: gli, iwalulya

! src/hotspot/share/gc/g1/g1HRPrinter.hpp

Changeset: fe23068d
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2024-05-02 08:43:57 +0000
URL:       https://git.openjdk.org/leyden/commit/fe23068d946181b0346e470d3172c5d29cc2e05c

8331392: G1: Make HRPrinter distinguish between different types of reclamation

Reviewed-by: ayang, iwalulya, gli

! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1HRPrinter.cpp
! src/hotspot/share/gc/g1/g1HRPrinter.hpp
! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp

Changeset: 286cbf83
Author:    Robbin Ehn <rehn at openjdk.org>
Date:      2024-05-02 09:58:32 +0000
URL:       https://git.openjdk.org/leyden/commit/286cbf831c2eb76e31bd69b4a93cd5ae9a821493

8331546: Build failure after 8330076

Reviewed-by: mdoerr, tschatzl, shade

! src/hotspot/share/memory/virtualspace.cpp

Changeset: ae82405f
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-05-02 10:08:29 +0000
URL:       https://git.openjdk.org/leyden/commit/ae82405ff7a48bc6e61b1d05bf74839b7ed50c11

8323058: Revisit j.l.classfile.CodeBuilder API surface

Reviewed-by: briangoetz, psandoz

! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
! src/java.base/share/classes/java/lang/classfile/package-info.java
! src/java.base/share/classes/java/lang/classfile/snippet-files/PackageSnippets.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java
! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
! src/java.base/share/classes/jdk/internal/classfile/impl/CatchBuilderImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassRemapperImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/CodeLocalsShifterImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/CodeRelabelerImpl.java
! src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/VersionPropsPlugin.java
! test/jdk/java/io/Serializable/records/ProhibitedMethods.java
! test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
! test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java
! test/jdk/java/lang/instrument/RetransformAgent.java
! test/jdk/java/lang/instrument/asmlib/Instrumentor.java
! test/jdk/java/lang/invoke/MethodHandleProxies/WrapperHiddenClassTest.java
! test/jdk/java/lang/invoke/MethodHandles/classData/ClassDataTest.java
! test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java
! test/jdk/java/lang/invoke/condy/CondyNestedTest.java
! test/jdk/java/lang/invoke/lookup/SpecialStatic.java
! test/jdk/java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java
! test/jdk/jdk/classfile/AdaptCodeTest.java
! test/jdk/jdk/classfile/BSMTest.java
! test/jdk/jdk/classfile/BuilderBlockTest.java
! test/jdk/jdk/classfile/BuilderTryCatchTest.java
! test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java
! test/jdk/jdk/classfile/LDCTest.java
! test/jdk/jdk/classfile/LowAdaptTest.java
! test/jdk/jdk/classfile/LvtTest.java
! test/jdk/jdk/classfile/OneToOneTest.java
! test/jdk/jdk/classfile/OpcodesValidationTest.java
! test/jdk/jdk/classfile/PrimitiveClassConstantTest.java
! test/jdk/jdk/classfile/ShortJumpsFixTest.java
! test/jdk/jdk/classfile/StackMapsTest.java
! test/jdk/jdk/classfile/StackTrackerTest.java
! test/jdk/jdk/classfile/TempConstantPoolBuilderTest.java
! test/jdk/jdk/classfile/TransformTests.java
! test/jdk/jdk/classfile/Utf8EntryTest.java
! test/jdk/jdk/classfile/WriteTest.java
! test/jdk/jdk/classfile/examples/ExampleGallery.java
! test/jdk/jdk/classfile/helpers/InstructionModelToCodeBuilder.java
! test/jdk/jdk/classfile/helpers/RebuildingTransformation.java
! test/jdk/jdk/classfile/helpers/Transforms.java
! test/jdk/jdk/lambda/separate/ClassToInterfaceConverter.java
! test/micro/org/openjdk/bench/java/lang/invoke/LazyStaticColdStart.java
! test/micro/org/openjdk/bench/jdk/classfile/RebuildMethodBodies.java
! test/micro/org/openjdk/bench/jdk/classfile/Transforms.java
! test/micro/org/openjdk/bench/jdk/classfile/Write.java

Changeset: beebce04
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2024-05-02 10:21:21 +0000
URL:       https://git.openjdk.org/leyden/commit/beebce044db97e50a7aea3f83d70e134b2128d0a

8331421: ubsan: vmreg.cpp checking error member call on misaligned address

Reviewed-by: mbaesken, lucy

! src/hotspot/share/code/vmreg.cpp
! src/hotspot/share/code/vmreg.hpp

Changeset: c9255f3f
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-05-02 10:46:29 +0000
URL:       https://git.openjdk.org/leyden/commit/c9255f3f5d3b826b9502e21aa953f0cf9f9abdec

8331514: Tests should not use the "Classpath" exception form of the legal header

Reviewed-by: dfuchs

! test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java

Changeset: 20569687
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-05-02 10:46:41 +0000
URL:       https://git.openjdk.org/leyden/commit/2056968777f3c8e3f783a8d52ff8a537c52fa8b1

8331513: Tests should not use the "Classpath" exception form of the legal header

Reviewed-by: dfuchs

! test/jdk/java/net/httpclient/RedirectTimeoutTest.java
! test/jdk/java/net/httpclient/http2/ExpectContinueResetTest.java

Changeset: 4a78906d
Author:    Christian Stein <cstein at openjdk.org>
Date:      2024-05-02 11:13:41 +0000
URL:       https://git.openjdk.org/leyden/commit/4a78906db1ebb56a759b43c2dfa909215491d4c0

8331537: Test code should not use the "Classpath" exception clause

Reviewed-by: jpai

! test/langtools/tools/javac/launcher/BasicSourceLauncherTests.java
! test/langtools/tools/javac/launcher/ModuleSourceLauncherTests.java
! test/langtools/tools/javac/launcher/MultiFileSourceLauncherTests.java
! test/langtools/tools/javac/launcher/ProgramDescriptorTests.java
! test/langtools/tools/javac/launcher/Run.java
! test/langtools/tools/javac/launcher/src/p/q/CLTest.java

Changeset: cccc9535
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2024-05-02 11:38:00 +0000
URL:       https://git.openjdk.org/leyden/commit/cccc95358d5c38cbcabc7f79abc53674deb1e6d8

8329258: TailCall should not use frame pointer register for jump target

Co-authored-by: Fei Yang <fyang at openjdk.org>
Reviewed-by: rcastanedalo, aph

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/riscv/riscv.ad
! src/hotspot/cpu/x86/x86_32.ad
! src/hotspot/cpu/x86/x86_64.ad
+ test/hotspot/jtreg/compiler/arraycopy/TestTailCallInArrayCopyStub.java

Changeset: c21672d8
Author:    Weibing Xiao <wxiao at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
Date:      2024-05-02 11:48:41 +0000
URL:       https://git.openjdk.org/leyden/commit/c21672d8c94da6aa613174744ceaa945ca2a474a

8331077: nroff man page update for jar tool

Reviewed-by: jjg, coffeys

! src/jdk.jartool/share/man/jar.1

Changeset: 257a07d5
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-05-02 12:20:07 +0000
URL:       https://git.openjdk.org/leyden/commit/257a07d5ca4d876f7f79a5f2598054ca261777ee

8331511: Tests should not use the "Classpath" exception form of the legal header

Reviewed-by: jpai

! test/jdk/jdk/classfile/OptionsTest.java

Changeset: 9912abf5
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
Date:      2024-05-02 12:20:18 +0000
URL:       https://git.openjdk.org/leyden/commit/9912abf586f4e0f76591639ae18d5c074edaa2c5

8331011: [XWayland] TokenStorage fails under Security Manager

Reviewed-by: prr, honkar, serb

! src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java

Changeset: a024eed7
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-05-02 12:42:59 +0000
URL:       https://git.openjdk.org/leyden/commit/a024eed7384828643e302f021a253717f53e3778

8331478: JFR: Rename printHelp methods for jdk.jfr.internal.dcmd classes

Reviewed-by: mgronlun

! src/hotspot/share/jfr/dcmd/jfrDcmds.cpp
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/AbstractDCmd.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdCheck.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdConfigure.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdDump.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdQuery.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStop.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdView.java

Changeset: 389f6fe9
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-05-02 13:41:29 +0000
URL:       https://git.openjdk.org/leyden/commit/389f6fe97c348e28d8573fe4754138d2a0bd6c0d

8331344: No compiler replay file with CompilerCommand MemLimit

Reviewed-by: kvn, asmehra

! src/hotspot/share/compiler/compilationMemoryStatistic.cpp
! src/hotspot/share/compiler/compilationMemoryStatistic.hpp
! test/hotspot/jtreg/compiler/print/CompileCommandMemLimit.java

Changeset: dd0b6418
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-05-02 13:48:36 +0000
URL:       https://git.openjdk.org/leyden/commit/dd0b6418191c765a92bfd03ec4d4206e0da7ee45

8330813: Don't call methods from Compressed(Oops|Klass) if the associated mode is inactive

Reviewed-by: stefank, asmehra

! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp

Changeset: 553d45b1
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
Date:      2024-05-02 13:53:45 +0000
URL:       https://git.openjdk.org/leyden/commit/553d45b11460a794613651373f34c8379c11729b

8323724: Remove potential re-inflation from FastHashCode under LM_LIGHTWEIGHT

Reviewed-by: aboldtch, coleenp

! src/hotspot/share/runtime/synchronizer.cpp

Changeset: 8771015d
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-05-02 14:32:03 +0000
URL:       https://git.openjdk.org/leyden/commit/8771015d7e3c4349ad58b58150a49217b1ffb902

8331027: JDK's ct.sym file packs corrupted module-info classes

Reviewed-by: asotona

! make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java
+ test/langtools/tools/javac/platform/VerifyCTSymClassFiles.java
! test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTest.java
! test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java

Changeset: 3383ad63
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-05-02 14:41:30 +0000
URL:       https://git.openjdk.org/leyden/commit/3383ad6397d5a2d8fb232ffd3e29a54e0b37b686

8331253: 16 bits is not enough for nmethod::_skipped_instructions_size field

Reviewed-by: dlong, thartmann

! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.cpp
! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp
! src/hotspot/share/asm/codeBuffer.cpp
! src/hotspot/share/asm/codeBuffer.hpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/code/nmethod.hpp
! src/hotspot/share/opto/output.cpp

Changeset: 7a41a525
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-05-02 15:03:48 +0000
URL:       https://git.openjdk.org/leyden/commit/7a41a525deb796396ade1456f1d0a101ac705014

8331549: Inline MemAllocator::mem_allocate_slow

Reviewed-by: stefank, gli

! src/hotspot/share/gc/shared/memAllocator.cpp
! src/hotspot/share/gc/shared/memAllocator.hpp

Changeset: 6969a9e0
Author:    Alisen Chung <achung at openjdk.org>
Date:      2024-05-02 15:36:10 +0000
URL:       https://git.openjdk.org/leyden/commit/6969a9e0b2143eee5a7cfa02460a8ab6dfa08cda

8328999: Update GIFlib to 5.2.2

Reviewed-by: tr, dnguyen, prr

! src/java.desktop/share/legal/giflib.md
! src/java.desktop/share/native/libsplashscreen/giflib/dgif_lib.c
! src/java.desktop/share/native/libsplashscreen/giflib/gif_err.c
! src/java.desktop/share/native/libsplashscreen/giflib/gif_hash.h
! src/java.desktop/share/native/libsplashscreen/giflib/gif_lib.h
! src/java.desktop/share/native/libsplashscreen/giflib/gif_lib_private.h
! src/java.desktop/share/native/libsplashscreen/giflib/gifalloc.c
! src/java.desktop/share/native/libsplashscreen/giflib/openbsd-reallocarray.c

Changeset: 6f98d8f5
Author:    Harshitha Onkar <honkar at openjdk.org>
Date:      2024-05-02 16:10:55 +0000
URL:       https://git.openjdk.org/leyden/commit/6f98d8f58f98827ae454c7ce4839de4071d95767

8329692: Add more details to FrameStateTest.java test instructions

Reviewed-by: tr, azvegint

! test/jdk/java/awt/Frame/FrameStateTest/FrameStateTest.java

Changeset: e2c0cfef
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-05-02 18:07:42 +0000
URL:       https://git.openjdk.org/leyden/commit/e2c0cfef1468e1081d1e68f74caae71266815cb6

8331320: ClassFile API OutOfMemoryError with certain class files

Reviewed-by: psandoz

! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java
! test/jdk/jdk/classfile/LimitsTest.java

Changeset: 73cdc9a0
Author:    Swati Sharma <swati.sharma at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
Date:      2024-05-02 18:28:50 +0000
URL:       https://git.openjdk.org/leyden/commit/73cdc9a070249791f7d228a93fe5b9335c5f72bd

8326421: Add jtreg test for large arrayCopy disjoint case.

Co-authored-by: Steve Dohrmann <steve.dohrmann at intel.com>
Reviewed-by: kvn, sviswanathan

+ test/hotspot/jtreg/compiler/arraycopy/TestArrayCopyDisjointLarge.java

Changeset: cd3a6075
Author:    Ben Perez <ben.perez at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
Date:      2024-05-02 18:50:38 +0000
URL:       https://git.openjdk.org/leyden/commit/cd3a607576bede17f48c3d5ebde2bf05f3b615ba

8328864: NullPointerException in sun.security.jca.ProviderList.getService()

Reviewed-by: weijun

! src/java.base/share/classes/sun/security/jca/ProviderList.java
+ test/jdk/sun/security/jca/NullPreferredList.java
+ test/jdk/sun/security/jca/app-security.properties

Changeset: 99654ec3
Author:    Phil Race <prr at openjdk.org>
Date:      2024-05-02 20:18:16 +0000
URL:       https://git.openjdk.org/leyden/commit/99654ec3fb2c2e7c8d5bf5965aaf45aeb4b88c61

8331516: Tests should not use the "Classpath" exception form of the legal header

Reviewed-by: iris, serb

! test/jdk/java/awt/font/GlyphVector/LayoutCompatTest.java

Changeset: f6cdcc6f
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
Date:      2024-05-02 20:18:25 +0000
URL:       https://git.openjdk.org/leyden/commit/f6cdcc6f65f2a436906541bb8266e69ded17e2e3

8280988: [XWayland] Click on title to request focus test failures

Reviewed-by: honkar, serb

! test/jdk/java/awt/Focus/6981400/Test1.java
! test/jdk/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java
! test/jdk/java/awt/Focus/ModalDialogInFocusEventTest.java
! test/jdk/java/awt/Mixing/AWT_Mixing/HierarchyBoundsListenerMixingTest.java
! test/lib/jdk/test/lib/Platform.java

Changeset: 04271dfe
Author:    SendaoYan <syan at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-05-02 21:19:16 +0000
URL:       https://git.openjdk.org/leyden/commit/04271dfe7a262379944e2a2cf83a98a3a1b78a74

8331331: :tier1 target explanation in doc/testing.md is incorrect

Reviewed-by: erikj, dholmes, ihse

! doc/testing.html
! doc/testing.md

Changeset: 01125fa2
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
Date:      2024-05-02 21:29:27 +0000
URL:       https://git.openjdk.org/leyden/commit/01125fa21b733199d4fe670ecf38b82cd917e242

8331605: jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java test failure

Reviewed-by: prr

! test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java

Changeset: 6bef0474
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2024-05-03 00:28:18 +0000
URL:       https://git.openjdk.org/leyden/commit/6bef0474c8b8773d0d20c0f25c36a2ce9cdbd7e8

8272364: Parallel GC adaptive size policy may shrink the heap below MinHeapSize

Reviewed-by: ayang, rkennke

! src/hotspot/share/gc/shared/genArguments.cpp
+ test/hotspot/jtreg/gc/arguments/TestParallelGCErgo.java

Changeset: 7c1fad4f
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-05-03 05:11:52 +0000
URL:       https://git.openjdk.org/leyden/commit/7c1fad4fb6c387bbfb72b3f96b610e7cbc2ef312

8329559: Test javax/swing/JFrame/bug4419914.java failed because The End and Start buttons are not placed correctly and Tab focus does not move as expected

Reviewed-by: abhiscxk, honkar, dnguyen

! test/jdk/javax/swing/JFrame/bug4419914.java

Changeset: 8bc641eb
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-05-03 05:49:39 +0000
URL:       https://git.openjdk.org/leyden/commit/8bc641ebe75ba4c975a99a8646b89ed10a7029f5

8331404: IGV: Show line numbers for callees in properties

Reviewed-by: tholenstein, thartmann

! src/hotspot/share/opto/idealGraphPrinter.cpp
! src/hotspot/share/opto/idealGraphPrinter.hpp

Changeset: a10845b5
Author:    Joachim Kern <jkern at openjdk.org>
Committer: Martin Doerr <mdoerr at openjdk.org>
Date:      2024-05-03 08:31:42 +0000
URL:       https://git.openjdk.org/leyden/commit/a10845b553fc6fe7e06a0f37ce73fe5f704dc7c4

8330539: Use #include <alloca.h> instead of -Dalloca'(size)'=__builtin_alloca'(size)' for AIX

Reviewed-by: jwaters, mdoerr, kbarrett, ihse

! make/autoconf/flags-cflags.m4
! src/hotspot/share/utilities/globalDefinitions_gcc.hpp

Changeset: f665e07a
Author:    Afshin Zafari <azafari at openjdk.org>
Date:      2024-05-03 10:17:11 +0000
URL:       https://git.openjdk.org/leyden/commit/f665e07ab223bdabb6cf3f653f799913d874bc55

8331540: [BACKOUT] NMT: add/make a mandatory MEMFLAGS argument to family of os::reserve/commit/uncommit memory API

Reviewed-by: jwilhelm

! src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp
! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/bsd/gc/x/xPhysicalMemoryBacking_bsd.cpp
! src/hotspot/os/bsd/gc/z/zPhysicalMemoryBacking_bsd.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/os/posix/perfMemory_posix.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/os/windows/perfMemory_windows.cpp
! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/classfile/compactHashtable.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1PageBasedVirtualSpace.cpp
! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp
! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp
! src/hotspot/share/gc/parallel/mutableSpace.cpp
! src/hotspot/share/gc/parallel/objectStartArray.cpp
! src/hotspot/share/gc/parallel/parMarkBitMap.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/parallel/psVirtualspace.cpp
! src/hotspot/share/gc/serial/serialBlockOffsetTable.cpp
! src/hotspot/share/gc/shared/cardTable.cpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/x/xMarkStackAllocator.cpp
! src/hotspot/share/gc/x/xPhysicalMemory.cpp
! src/hotspot/share/gc/x/xVirtualMemory.cpp
! src/hotspot/share/gc/z/zMarkStackAllocator.cpp
! src/hotspot/share/gc/z/zNMT.cpp
! src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp
! src/hotspot/share/memory/allocation.inline.hpp
! src/hotspot/share/memory/heap.cpp
! src/hotspot/share/memory/metaspace.cpp
! src/hotspot/share/memory/metaspace/testHelpers.cpp
! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp
! src/hotspot/share/memory/virtualspace.cpp
! src/hotspot/share/memory/virtualspace.hpp
! src/hotspot/share/nmt/memTracker.hpp
! src/hotspot/share/nmt/virtualMemoryTracker.cpp
! src/hotspot/share/nmt/virtualMemoryTracker.hpp
! src/hotspot/share/oops/compressedKlass.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! src/hotspot/share/runtime/safepointMechanism.cpp
! src/hotspot/share/utilities/debug.cpp
! test/hotspot/gtest/gc/g1/test_freeRegionList.cpp
! test/hotspot/gtest/gc/g1/test_stressCommitUncommit.cpp
! test/hotspot/gtest/gc/z/test_zForwarding.cpp
! test/hotspot/gtest/memory/test_virtualspace.cpp
! test/hotspot/gtest/nmt/test_nmt_locationprinting.cpp
! test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp
! test/hotspot/gtest/runtime/test_os.cpp
! test/hotspot/gtest/runtime/test_os_linux.cpp
! test/hotspot/gtest/runtime/test_os_reserve_between.cpp
! test/hotspot/gtest/runtime/test_os_windows.cpp
! test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp

Changeset: f78fa055
Author:    Afshin Zafari <azafari at openjdk.org>
Date:      2024-05-03 10:17:23 +0000
URL:       https://git.openjdk.org/leyden/commit/f78fa0556d93d8ec98f403694e067611e4501fd4

8331636: [BACKOUT] Build failure after 8330076

Reviewed-by: jwilhelm

! src/hotspot/share/memory/virtualspace.cpp

Changeset: c60474b1
Author:    Chen Liang <liach at openjdk.org>
Committer: Adam Sotona <asotona at openjdk.org>
Date:      2024-05-03 11:08:33 +0000
URL:       https://git.openjdk.org/leyden/commit/c60474b1229b67265acbd709f6ba081303329be4

8323707: Adjust Classfile API's type arg model to better represent the embodied type

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/Signature.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassRemapperImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/SignaturesImpl.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java
! test/jdk/jdk/classfile/SignaturesTest.java
! test/langtools/tools/javap/classfile/6888367/T6888367.java

Changeset: 1f6d38f7
Author:    Chen Liang <liach at openjdk.org>
Committer: Adam Sotona <asotona at openjdk.org>
Date:      2024-05-03 11:57:10 +0000
URL:       https://git.openjdk.org/leyden/commit/1f6d38f7a63c6cb429953c5e9bb0b9f365bfcabe

8294978: Convert 5 test/jdk/jdk/jfr tests from ASM library to Classfile API

Reviewed-by: asotona

! test/jdk/jdk/jfr/event/compiler/TestCompilerInlining.java
! test/jdk/jdk/jfr/event/io/TestInstrumentation.java
! test/jdk/jdk/jfr/javaagent/TestEventInstrumentation.java
! test/jdk/jdk/jfr/jvm/TestLargeJavaEvent512k.java
! test/jdk/jdk/jfr/jvm/TestLargeJavaEvent64k.java

Changeset: 8ed31902
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2024-05-03 12:03:28 +0000
URL:       https://git.openjdk.org/leyden/commit/8ed319023e921a980ea197fbffe417f35fc59b94

8331401: G1: Make G1HRPrinter AllStatic

Reviewed-by: iwalulya, ayang, gli

! src/hotspot/share/gc/g1/g1Allocator.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1HRPrinter.hpp
! src/hotspot/share/gc/g1/g1HeapRegionManager.cpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
! src/hotspot/share/gc/g1/g1YoungCollector.cpp
! src/hotspot/share/gc/g1/g1YoungCollector.hpp
! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp

Changeset: 3c77dad0
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-05-03 12:06:11 +0000
URL:       https://git.openjdk.org/leyden/commit/3c77dad007df2329eb653264cb8e0273f09fabfe

8331507: JFR: Improve example usage in -XX:StartFlightRecording:help

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java

Changeset: 58ef9e48
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2024-05-03 12:33:41 +0000
URL:       https://git.openjdk.org/leyden/commit/58ef9e4805c0cc78935eb5a1c82ae10411d52e85

8331402: G1: Remove is_active() calls in G1HRPrinter logging

Reviewed-by: iwalulya, ayang, gli

! src/hotspot/share/gc/g1/g1HRPrinter.hpp

Changeset: ce73fec8
Author:    Ivan Walulya <iwalulya at openjdk.org>
Date:      2024-05-03 12:35:58 +0000
URL:       https://git.openjdk.org/leyden/commit/ce73fec882357d749619576a3219516b7391fb3f

8331048: G1: Prune rebuild candidates based on G1HeapWastePercent early

Reviewed-by: ayang, tschatzl

! src/hotspot/share/gc/g1/g1CollectionSetCandidates.cpp
! src/hotspot/share/gc/g1/g1CollectionSetCandidates.hpp
! src/hotspot/share/gc/g1/g1CollectionSetChooser.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1Policy.cpp
! src/hotspot/share/gc/g1/g1Policy.hpp

Changeset: 9697bc38
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-05-03 13:02:37 +0000
URL:       https://git.openjdk.org/leyden/commit/9697bc38586059d9bb020d3ca44a1c6cd7de315c

8331428: ubsan: JVM flag checking complains about  MaxTenuringThresholdConstraintFunc, InitialTenuringThresholdConstraintFunc and AllocatePrefetchStepSizeConstraintFunc

Reviewed-by: stefank, aboldtch, tschatzl

! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp
! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.hpp
! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp
! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.hpp

Changeset: 1d083eb1
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2024-05-03 13:10:00 +0000
URL:       https://git.openjdk.org/leyden/commit/1d083eb15a653dbfbd262de76c1312207192bda7

8331562: G1: Remove API to force allocation of new regions

Reviewed-by: iwalulya, ayang, gli

! src/hotspot/share/gc/g1/g1AllocRegion.cpp
! src/hotspot/share/gc/g1/g1AllocRegion.hpp
! src/hotspot/share/gc/g1/g1AllocRegion.inline.hpp
! src/hotspot/share/gc/g1/g1Allocator.hpp
! src/hotspot/share/gc/g1/g1Allocator.inline.hpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1HRPrinter.hpp

Changeset: 37c24695
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-05-03 13:27:58 +0000
URL:       https://git.openjdk.org/leyden/commit/37c24695390e409aae6df9f7d2ecc86724dd051d

8331633: Use MIN2 in bound_minus_alignment

Reviewed-by: zgu

! src/hotspot/share/gc/shared/genArguments.cpp

Changeset: 87bb66ce
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2024-05-03 13:39:48 +0000
URL:       https://git.openjdk.org/leyden/commit/87bb66cea1b6b70fc4929e7a6e3788883f87e02d

8331569: G1: Rename G1HRPrinter to G1HeapRegionPrinter

Reviewed-by: gli, ayang

! src/hotspot/share/gc/g1/g1Allocator.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
- src/hotspot/share/gc/g1/g1HRPrinter.cpp
! src/hotspot/share/gc/g1/g1HeapRegionManager.cpp
+ src/hotspot/share/gc/g1/g1HeapRegionPrinter.cpp
= src/hotspot/share/gc/g1/g1HeapRegionPrinter.hpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
! src/hotspot/share/gc/g1/g1YoungCollector.cpp
! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp

Changeset: 77b71222
Author:    Sean Coffey <coffeys at openjdk.org>
Date:      2024-05-03 15:18:38 +0000
URL:       https://git.openjdk.org/leyden/commit/77b71222a05a5ef3875a71eda26e31b25548cba2

8312104: Update java man pages to include new security category in -XshowSettings

Reviewed-by: lancea

! src/java.base/share/man/java.1

Changeset: cf2c80e4
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-05-03 16:14:24 +0000
URL:       https://git.openjdk.org/leyden/commit/cf2c80e4fcd74b9d1d60e2358e7883bdd8a4ac80

8331582: Incorrect default Console provider comment

Reviewed-by: joehw, jlahoda, jlu, prappo

! src/java.base/share/classes/java/io/Console.java

Changeset: b33096f8
Author:    Justin Lu <jlu at openjdk.org>
Date:      2024-05-03 16:58:59 +0000
URL:       https://git.openjdk.org/leyden/commit/b33096f887108c3d7e1f4e62689c2b10401234fa

8295153: java/util/Base64/TestEncodingDecodingLength.java ran out of memory

Reviewed-by: lancea, naoto

! test/jdk/java/util/Base64/TestEncodingDecodingLength.java

Changeset: 36c9607f
Author:    Phil Race <prr at openjdk.org>
Date:      2024-05-03 19:06:13 +0000
URL:       https://git.openjdk.org/leyden/commit/36c9607f66f91a0c46342543b30b57ac1cf106ec

8331591: sun.font.CharSequenceCodePointIterator is buggy and unused

Reviewed-by: angorya, honkar

! src/java.desktop/share/classes/sun/font/CodePointIterator.java

Changeset: c1a16452
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-05-03 19:15:12 +0000
URL:       https://git.openjdk.org/leyden/commit/c1a164528a538d5de78f99c4c92291b1906703f5

8331655: ClassFile API ClassCastException with verbose output of certain class files

Reviewed-by: psandoz

! src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java
! test/jdk/jdk/classfile/LimitsTest.java

Changeset: b20fa7b4
Author:    Doug Simon <dnsimon at openjdk.org>
Date:      2024-05-03 19:51:37 +0000
URL:       https://git.openjdk.org/leyden/commit/b20fa7b48b0f0a64c0760f26188d4c11c3233b61

8329982: compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/SimpleDebugInfoTest.java failed assert(oopDesc::is_oop_or_null(val)) failed: bad oop found

Reviewed-by: never

! src/hotspot/share/gc/shared/barrierSetNMethod.cpp
! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/jvmci/jvmciRuntime.hpp
- test/hotspot/jtreg/compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java
- test/hotspot/jtreg/compiler/jvmci/events/JvmciNotifyInstallEventTest.config
- test/hotspot/jtreg/compiler/jvmci/events/JvmciNotifyInstallEventTest.java
! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/CodeInstallationTest.java
+ test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/RuntimeStubAllocFailTest.java
! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/SimpleCodeInstallationTest.java
! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/TestAssembler.java
! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/TestHotSpotVMConfig.java
! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/aarch64/AArch64TestAssembler.java
! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/amd64/AMD64TestAssembler.java

Changeset: 9347bb7d
Author:    Cesar Soares Lucas <cslucas at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-05-03 23:41:12 +0000
URL:       https://git.openjdk.org/leyden/commit/9347bb7df845ee465c378c6f511ef8a6caea18ea

8330247: C2: CTW fail with assert(adr_t->is_known_instance_field()) failed: instance required

Reviewed-by: kvn

! src/hotspot/share/opto/macro.cpp
+ test/hotspot/jtreg/compiler/c2/TestReduceAllocationAndNonExactAllocate.java

Changeset: f2c4a413
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-05-06 05:49:28 +0000
URL:       https://git.openjdk.org/leyden/commit/f2c4a41304d4fe984b79792cb3be460d7026e812

8328481: Implement JEP 476: Module Import Declarations (Preview)

Co-authored-by: Jim Laskey <jlaskey at openjdk.org>
Reviewed-by: mcimadamore, vromero

! src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
! src/jdk.compiler/share/classes/com/sun/source/tree/ImportTree.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/comp/Check.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeDiffer.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.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/TreeMaker.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Startup.java
! src/jdk.jshell/share/classes/jdk/jshell/Eval.java
! src/jdk.jshell/share/classes/jdk/jshell/Snippet.java
+ src/jdk.jshell/share/classes/jdk/jshell/tool/resources/PREVIEW_DEFAULT.jsh
! test/langtools/jdk/jshell/ImportTest.java
! test/langtools/jdk/jshell/KullaTesting.java
! test/langtools/jdk/jshell/StartOptionTest.java
! test/langtools/jdk/jshell/ToolProviderTest.java
+ test/langtools/tools/javac/ImportModule.java
+ test/langtools/tools/javac/diags/examples/ImportModule.java
+ test/langtools/tools/javac/diags/examples/ImportModuleDoesNotRead/module-info.java
= test/langtools/tools/javac/diags/examples/ImportModuleDoesNotRead/test/Test.java
+ test/langtools/tools/javac/diags/examples/ImportModuleDoesNotReadUnnamed.java
+ test/langtools/tools/javac/diags/examples/ImportModuleNotFound.java
+ test/langtools/tools/javac/tree/Imports.java
! test/langtools/tools/jdeps/listdeps/ListModuleDeps.java
! test/langtools/tools/lib/toolbox/ToolBox.java

Changeset: f1509e00
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-05-06 06:01:42 +0000
URL:       https://git.openjdk.org/leyden/commit/f1509e007d1538acfb1749f7fafc56be2affd2e6

8330998: System.console() writes to stderr when stdout is redirected

Reviewed-by: naoto

! src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/TerminalBuilder.java
+ test/jdk/jdk/internal/jline/RedirectedStdOut.java

Changeset: 4bbd972c
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-05-06 07:48:22 +0000
URL:       https://git.openjdk.org/leyden/commit/4bbd972cbb114b99e856aa7904c0240049052b6a

8305638: Renaming and small clean-ups around predicates

Reviewed-by: roland, epeter

! src/hotspot/share/opto/cfgnode.hpp
! src/hotspot/share/opto/loopPredicate.cpp
! src/hotspot/share/opto/loopTransform.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/loopnode.hpp

Changeset: 15862a2f
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-05-06 08:48:46 +0000
URL:       https://git.openjdk.org/leyden/commit/15862a2f116331b7f439619c3aa1b5965e737044

8331708: jdk/internal/jline/RedirectedStdOut.java times-out on macosx-aarch64

Reviewed-by: asotona

! test/jdk/jdk/internal/jline/RedirectedStdOut.java

Changeset: 6c776411
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
Date:      2024-05-06 09:26:53 +0000
URL:       https://git.openjdk.org/leyden/commit/6c7764118ef1a684edddb302a4eaff36d80c783f

8331418: ZGC: generalize barrier liveness logic

Reviewed-by: mdoerr, aboldtch, fyang, eosterlund

! src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp
! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.hpp
! src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp
! src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp
! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp
! src/hotspot/share/gc/shared/c2/barrierSetC2.hpp
! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
! src/hotspot/share/gc/z/c2/zBarrierSetC2.hpp

Changeset: 9b0bb033
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-05-06 09:41:07 +0000
URL:       https://git.openjdk.org/leyden/commit/9b0bb03366642dd787b02809b3759ed714da9b81

8331285: Deprecate and obsolete OldSize

Reviewed-by: dholmes, eosterlund

! src/hotspot/share/gc/shared/gc_globals.hpp
! src/hotspot/share/runtime/arguments.cpp

Changeset: e8a2d566
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-05-06 11:01:55 +0000
URL:       https://git.openjdk.org/leyden/commit/e8a2d5669cda59d0f9a10e5a8035c20b8678d3d8

8331653: JFR: Improve logging for jdk/jfr/api/consumer/recordingstream;TestStop.java

Reviewed-by: mgronlun

! test/jdk/jdk/jfr/api/consumer/recordingstream/TestStop.java

Changeset: 1eec30a6
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-05-06 11:17:39 +0000
URL:       https://git.openjdk.org/leyden/commit/1eec30a6c03b7f4028405dc9bdb4d2a663b3987d

8331573: Rename CollectedHeap::is_gc_active to be explicitly about STW GCs

Reviewed-by: stefank, zgu, tschatzl, gli

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp
! src/hotspot/share/gc/g1/g1FullGCScope.hpp
! src/hotspot/share/gc/g1/g1RemSet.cpp
! src/hotspot/share/gc/g1/g1VMOperations.cpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/parallel/psScavenge.cpp
! src/hotspot/share/gc/serial/serialHeap.cpp
! src/hotspot/share/gc/shared/collectedHeap.cpp
! src/hotspot/share/gc/shared/collectedHeap.hpp
! src/hotspot/share/gc/shared/isGCActiveMark.cpp
! src/hotspot/share/gc/shared/isGCActiveMark.hpp
! src/hotspot/share/gc/shared/memAllocator.cpp
! src/hotspot/share/gc/shared/vmStructs_gc.hpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp
! src/hotspot/share/gc/x/xDriver.cpp
! src/hotspot/share/gc/z/zGeneration.cpp
! src/hotspot/share/gc/z/zVerify.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/memory/universe.hpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/oops/oop.cpp
! src/hotspot/share/prims/forte.cpp
! src/hotspot/share/runtime/jniHandles.cpp

Changeset: a8e62af7
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2024-05-06 11:43:07 +0000
URL:       https://git.openjdk.org/leyden/commit/a8e62af733cb1acc1370561c9dd374b3f9c2c294

8331389: runtime/ErrorHandling/TestDwarf.java fails with "Crash JVM should not exit gracefully"

Reviewed-by: chagedorn

! test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java

Changeset: fa02667d
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
Date:      2024-05-06 12:21:15 +0000
URL:       https://git.openjdk.org/leyden/commit/fa02667d838f08cac7d41dfb4c3e8056ae6165cc

8322726: C2: Unloaded signature class kills argument value

Reviewed-by: kvn, dlong, thartmann

! src/hotspot/share/opto/callGenerator.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/graphKit.hpp
+ test/hotspot/jtreg/compiler/runtime/unloaded/TestMHUnloaded.java
+ test/hotspot/jtreg/compiler/runtime/unloaded/TestMHUnloadedHelper.java

Changeset: 7a35f922
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2024-05-06 13:25:36 +0000
URL:       https://git.openjdk.org/leyden/commit/7a35f922f06c4649f9ea8a1fb1782b2a670311ce

8331660: Parallel: Cleanup includes in parallelScavangeHeap files

Reviewed-by: gli, ayang

! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.inline.hpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.hpp
! src/hotspot/share/gc/parallel/psScavenge.cpp
! src/hotspot/share/gc/parallel/psScavenge.hpp
! src/hotspot/share/gc/parallel/psVMOperations.cpp

Changeset: ae60d845
Author:    Nizar Benalla <nizar.benalla at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
Date:      2024-05-06 15:54:40 +0000
URL:       https://git.openjdk.org/leyden/commit/ae60d845007c7137895e3a5f86623d0731fee81f

8328501: Incorrect `@since` tags for java security interfaces

Reviewed-by: mullan

! src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java
! src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java
! src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java
! src/java.base/share/classes/java/security/interfaces/ECPublicKey.java
! src/java.base/share/classes/java/security/interfaces/EdECPrivateKey.java
! src/java.base/share/classes/java/security/interfaces/EdECPublicKey.java
! src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java
! src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java
! src/java.base/share/classes/java/security/interfaces/XECPrivateKey.java
! src/java.base/share/classes/java/security/interfaces/XECPublicKey.java
! src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java
! src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java

Changeset: a8b3f194
Author:    Fabian Meumertzheim <fabian at meumertzhe.im>
Committer: Brian Burkhalter <bpb at openjdk.org>
Date:      2024-05-06 17:01:11 +0000
URL:       https://git.openjdk.org/leyden/commit/a8b3f194e811eed6b20bce71c752705c7cd50d24

8330077: Allow max number of events to be buffered to be configurable to avoid OVERFLOW_EVENT

Reviewed-by: bpb, alanb

! src/java.base/share/classes/java/nio/file/WatchService.java
! src/java.base/share/classes/sun/nio/fs/AbstractWatchKey.java
+ test/jdk/java/nio/file/WatchService/LotsOfEntries.java

Changeset: f308e107
Author:    Bhavana Kilambi <bkilambi at openjdk.org>
Committer: Eric Liu <eliu at openjdk.org>
Date:      2024-05-06 22:59:14 +0000
URL:       https://git.openjdk.org/leyden/commit/f308e107ce8b993641ee3d0a0d5d52bf5cd3b94e

8331400: AArch64: Sync aarch64_vector.ad with aarch64_vector_ad.m4

Reviewed-by: aph, kvn, eliu

! src/hotspot/cpu/aarch64/aarch64_vector.ad
! src/hotspot/cpu/aarch64/aarch64_vector_ad.m4

Changeset: 3b8227ba
Author:    Nizar Benalla <nizar.benalla at oracle.com>
Committer: Adam Sotona <asotona at openjdk.org>
Date:      2024-05-07 05:28:45 +0000
URL:       https://git.openjdk.org/leyden/commit/3b8227ba24c7bc05a8ea23801e3816e8fc80de4e

8326836: Incorrect `@since` tags for ClassSignature methods

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/ClassSignature.java

Changeset: df1ff056
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-05-07 07:08:32 +0000
URL:       https://git.openjdk.org/leyden/commit/df1ff056f19ce569e05b0b87584e289840fc5d5c

8331085: Crash in MergePrimitiveArrayStores::is_compatible_store()

Reviewed-by: thartmann, chagedorn

! src/hotspot/share/opto/memnode.cpp
+ test/hotspot/jtreg/compiler/c2/TestMergeStoresNullAdrType.java

Changeset: a2584a83
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-05-07 08:30:26 +0000
URL:       https://git.openjdk.org/leyden/commit/a2584a8341b2dc9c102abd373a890b2108d3f57e

8331714: Make OopMapCache installation lock-free

Reviewed-by: zgu, coleenp

! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp

Changeset: 23a72a1f
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2024-05-07 08:32:48 +0000
URL:       https://git.openjdk.org/leyden/commit/23a72a1f2f651d5e8e9a0eb1e75e2b44572a13da

8331626: unsafe.cpp:162:38: runtime error in index_oop_from_field_offset_long - applying non-zero offset 4563897424 to null pointer

Reviewed-by: mbaesken, stefank

! src/hotspot/share/prims/unsafe.cpp

Changeset: 02a799c0
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2024-05-07 12:41:28 +0000
URL:       https://git.openjdk.org/leyden/commit/02a799c05576a52b03b74a4ece901e7811dfda76

8331695: Serial: DefNewGeneration:_promotion_failed used without being initialized

Reviewed-by: gli, stefank

! src/hotspot/share/gc/serial/defNewGeneration.cpp

Changeset: 02c95a6d
Author:    robertengels <robaho at me.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-05-07 13:18:24 +0000
URL:       https://git.openjdk.org/leyden/commit/02c95a6d7eb77ed17ae64d0f585197e87a67cc4a

6968351: httpserver clashes with delayed TCP ACKs for low Content-Length

Reviewed-by: dfuchs, djelinski, michaelm, jpai

! src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedOutputStream.java
! src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java
! src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java
+ test/jdk/com/sun/net/httpserver/TcpNoDelayNotRequired.java
! test/jdk/com/sun/net/httpserver/simpleserver/StressDirListings.java
! test/jdk/java/net/Authenticator/B4769350.java
! test/jdk/sun/net/www/http/KeepAliveCache/B8293562.java

Changeset: 5746137e
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-05-07 14:23:39 +0000
URL:       https://git.openjdk.org/leyden/commit/5746137e8a46e1eb964fe8c4de015a62dc17a745

8331771: ZGC: Remove OopMapCacheAlloc_lock ordering workaround

Reviewed-by: eosterlund, stefank, zgu

! src/hotspot/share/gc/shared/collectedHeap.hpp
! src/hotspot/share/gc/shared/isGCActiveMark.cpp
! src/hotspot/share/gc/shared/isGCActiveMark.hpp
! src/hotspot/share/gc/z/zVerify.cpp

Changeset: 95d2f807
Author:    Daniel Skantz <daniel.skantz at oracle.com>
Committer: Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-05-07 15:50:15 +0000
URL:       https://git.openjdk.org/leyden/commit/95d2f8072e91e8df80e49e341f4fdb4464a2616e

8330016: Stress seed should be initialized for runtime stub compilation

Reviewed-by: rcastanedalo, chagedorn

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp

Changeset: 524aaad9
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
Committer: Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-05-07 15:59:44 +0000
URL:       https://git.openjdk.org/leyden/commit/524aaad98317b1a50453e5a9a44922f481fb3b1e

8319957: PhaseOutput::code_size is unused and should be removed

Reviewed-by: thartmann, chagedorn

! src/hotspot/share/opto/output.cpp
! src/hotspot/share/opto/output.hpp

Changeset: 8d78e8ca
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-05-07 18:59:41 +0000
URL:       https://git.openjdk.org/leyden/commit/8d78e8cadcc06aea7179ec97d3bf8b7cee63b447

8319997: JFR: Reduce use of dynamic proxies

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/EventType.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/AnnotationConstruct.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/Type.java

Changeset: f12ed061
Author:    Viktor Klang <vklang at openjdk.org>
Date:      2024-05-07 19:06:36 +0000
URL:       https://git.openjdk.org/leyden/commit/f12ed061ae3fa9d5620a7c6c7ea441f9f33bb745

8048691: Spliterator.SORTED characteristics gets cleared for BaseStream.spliterator

Reviewed-by: psandoz, alanb

! src/java.base/share/classes/java/util/stream/StreamSpliterators.java
! test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java

Changeset: b9108334
Author:    Weijun Wang <weijun at openjdk.org>
Date:      2024-05-07 23:46:04 +0000
URL:       https://git.openjdk.org/leyden/commit/b91083341aba952befadd79020079920f9540999

8331864: Update Public Suffix List to 1cbd6e7

Reviewed-by: mullan

! src/java.base/share/data/publicsuffixlist/VERSION
! src/java.base/share/data/publicsuffixlist/public_suffix_list.dat
! src/java.base/share/legal/public_suffix.md
! test/jdk/sun/security/util/RegisteredDomain/ParseNames.java
! test/jdk/sun/security/util/RegisteredDomain/tests.dat

Changeset: 8af606fb
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-05-08 01:12:17 +0000
URL:       https://git.openjdk.org/leyden/commit/8af606fb8cdb3a6ecdfe4cddd79f228b64d5fc80

8331334: com/sun/net/httpserver/HttpsParametersClientAuthTest.java fails in testServerNeedClientAuth(false)

Reviewed-by: dfuchs

! test/jdk/com/sun/net/httpserver/HttpsParametersClientAuthTest.java

Changeset: 466a21d8
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2024-05-08 05:03:06 +0000
URL:       https://git.openjdk.org/leyden/commit/466a21d8646c05d91f29d607c6347afd34c75629

8331863: DUIterator_Fast used before it is constructed

Reviewed-by: kvn, shade

! src/hotspot/share/opto/node.hpp

Changeset: 7b79426a
Author:    Christian Stein <cstein at openjdk.org>
Date:      2024-05-08 05:48:07 +0000
URL:       https://git.openjdk.org/leyden/commit/7b79426a1da5896b0f00cf6e5fb4d2e754149e54

8278353: Provide Duke as default favicon in Simple Web Server

Reviewed-by: dfuchs

! make/modules/jdk.httpserver/Java.gmk
! src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java
+ src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/resources/favicon.ico
! test/jdk/com/sun/net/httpserver/simpleserver/SimpleFileServerTest.java

Changeset: 2baacfc1
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-05-08 07:05:27 +0000
URL:       https://git.openjdk.org/leyden/commit/2baacfc16916220846743c6e49a99a6c41cac510

8331789: ubsan: deoptimization.cpp:403:29: runtime error: load of value 208, which is not a valid value for type 'bool'

Reviewed-by: stefank, aboldtch

! src/hotspot/share/runtime/deoptimization.cpp

Changeset: 7f299043
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
Date:      2024-05-08 08:27:13 +0000
URL:       https://git.openjdk.org/leyden/commit/7f299043a99406dbd666d4f7f30445d26f3eae82

8330005: RandomGeneratorFactory.getDefault() throws exception when the runtime image only has java.base module

Reviewed-by: jpai, alanb

! src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java
! src/java.base/share/classes/java/util/random/package-info.java
= src/java.base/share/classes/jdk/internal/random/L128X1024MixRandom.java
= src/java.base/share/classes/jdk/internal/random/L128X128MixRandom.java
= src/java.base/share/classes/jdk/internal/random/L128X256MixRandom.java
= src/java.base/share/classes/jdk/internal/random/L32X64MixRandom.java
= src/java.base/share/classes/jdk/internal/random/L64X1024MixRandom.java
= src/java.base/share/classes/jdk/internal/random/L64X128MixRandom.java
= src/java.base/share/classes/jdk/internal/random/L64X128StarStarRandom.java
= src/java.base/share/classes/jdk/internal/random/L64X256MixRandom.java
= src/java.base/share/classes/jdk/internal/random/Xoroshiro128PlusPlus.java
= src/java.base/share/classes/jdk/internal/random/Xoshiro256PlusPlus.java
! src/java.base/share/classes/module-info.java
- src/jdk.random/share/classes/module-info.java

Changeset: 0e1dca75
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-05-08 08:45:27 +0000
URL:       https://git.openjdk.org/leyden/commit/0e1dca75ef1f145bcf1ad76a2bf21d647ddaf76b

8331715: Remove virtual specifiers in ContiguousSpace

Reviewed-by: gli, tschatzl

! src/hotspot/share/gc/shared/space.hpp

Changeset: c6f611cf
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-05-08 08:48:11 +0000
URL:       https://git.openjdk.org/leyden/commit/c6f611cfe0f3d6807b450be19ec00713229dbf42

8331798: Remove unused arg of checkErgonomics() in TestMaxHeapSizeTools.java

Reviewed-by: tschatzl

! test/hotspot/jtreg/gc/arguments/TestMaxHeapSizeTools.java

Changeset: 0eff492e
Author:    Sean Coffey <coffeys at openjdk.org>
Date:      2024-05-08 09:30:23 +0000
URL:       https://git.openjdk.org/leyden/commit/0eff492e4107abc5624f0c3445877bf38629a980

8330278: Have SSLSocketTemplate.doClientSide use loopback address

Reviewed-by: ssahoo, rhalade

! test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java
! test/jdk/javax/net/ssl/templates/TLSBase.java

Changeset: 1aebab78
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-05-08 09:37:42 +0000
URL:       https://git.openjdk.org/leyden/commit/1aebab780c5b84a85b6f10884d05bb29bae3c3bf

8320995: RISC-V: C2 PopCountVI
8320996: RISC-V: C2 PopCountVL

Reviewed-by: luhenry, fyang

! src/hotspot/cpu/riscv/assembler_riscv.hpp
! src/hotspot/cpu/riscv/globals_riscv.hpp
! src/hotspot/cpu/riscv/riscv_v.ad
! src/hotspot/cpu/riscv/vm_version_riscv.cpp
! src/hotspot/cpu/riscv/vm_version_riscv.hpp
! test/hotspot/jtreg/compiler/lib/ir_framework/test/IREncodingPrinter.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestGeneralizedReductions.java
! test/hotspot/jtreg/compiler/vectorization/TestPopCountVector.java
! test/hotspot/jtreg/compiler/vectorization/TestPopCountVectorLong.java

Changeset: edd47c10
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-05-08 10:11:01 +0000
URL:       https://git.openjdk.org/leyden/commit/edd47c10ebfdc021368820dec6a109251554e8b0

8308033: The jcmd thread dump related tests should test virtual threads

Reviewed-by: cjplummer, sspitsyn

! test/hotspot/jtreg/ProblemList-Virtual.txt
! test/hotspot/jtreg/serviceability/dcmd/thread/PrintTest.java
! test/hotspot/jtreg/serviceability/tmtools/jstack/DaemonThreadTest.java
! test/jdk/ProblemList-Virtual.txt
! test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java
! test/jdk/sun/tools/jstack/BasicJStackTest.java

Changeset: aafa15fc
Author:    Doug Simon <dnsimon at openjdk.org>
Date:      2024-05-08 10:18:33 +0000
URL:       https://git.openjdk.org/leyden/commit/aafa15fc173af07ebf5361a8c6a09c2a28981c38

8331208: Memory stress test that checks OutOfMemoryError stack trace fails

Reviewed-by: dholmes, never

! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/gc/shared/memAllocator.cpp
! src/hotspot/share/gc/shared/memAllocator.hpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/memory/universe.hpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/thread.hpp

Changeset: ad78b7fa
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-05-08 10:38:09 +0000
URL:       https://git.openjdk.org/leyden/commit/ad78b7fa67ba30cab2e8f496e4c765be15deeca6

8331185: Enable compiler memory limits in debug builds

Reviewed-by: asmehra, kvn

! src/hotspot/share/compiler/compilationMemoryStatistic.cpp
! src/hotspot/share/compiler/compilerOracle.cpp
! src/hotspot/share/compiler/compilerOracle.hpp
! test/hotspot/jtreg/compiler/c2/TestFindNode.java
! test/hotspot/jtreg/compiler/loopopts/TestDeepGraphVerifyIterativeGVN.java
! test/hotspot/jtreg/compiler/print/CompileCommandMemLimit.java
! test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java

Changeset: aee254fa
Author:    Igor Veresov <igor.veresov at oracle.com>
Date:      2024-05-08 11:09:17 +0000
URL:       https://git.openjdk.org/leyden/commit/aee254fa34d4ca1c3871c9e3b700a21413baf323

Merge branch 'master' 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/templateTable_x86.cpp
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/asm/codeBuffer.cpp
! src/hotspot/share/asm/codeBuffer.hpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/code/nmethod.hpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/compiler/compileTask.cpp
! src/hotspot/share/compiler/compileTask.hpp
! src/hotspot/share/compiler/compilerOracle.cpp
! src/hotspot/share/compiler/compilerOracle.hpp
! src/hotspot/share/gc/shared/barrierSetNMethod.cpp
! 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/method.cpp
! src/hotspot/share/oops/oop.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/graphKit.hpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/output.cpp
! src/hotspot/share/prims/unsafe.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/thread.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/TestHotSpotVMConfig.java
! 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/templateTable_x86.cpp
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/asm/codeBuffer.cpp
! src/hotspot/share/asm/codeBuffer.hpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/code/nmethod.hpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/compiler/compileTask.cpp
! src/hotspot/share/compiler/compileTask.hpp
! src/hotspot/share/compiler/compilerOracle.cpp
! src/hotspot/share/compiler/compilerOracle.hpp
! src/hotspot/share/gc/shared/barrierSetNMethod.cpp
! 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/method.cpp
! src/hotspot/share/oops/oop.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/graphKit.hpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/output.cpp
! src/hotspot/share/prims/unsafe.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/thread.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/TestHotSpotVMConfig.java


From duke at openjdk.org  Thu May  9 20:57:30 2024
From: duke at openjdk.org (duke)
Date: Thu, 9 May 2024 20:57:30 GMT
Subject: git: openjdk/leyden: premain: 13 new changesets
Message-ID: <da16d11b-d89e-4e22-b6ff-c7d8b1130ba5@openjdk.org>

Changeset: c8452615
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-05-08 17:56:28 +0000
URL:       https://git.openjdk.org/leyden/commit/c8452615b1f3c4e03caf70e2c72928d49cb816a7

8331924: Parallel: Remove unused MutableSpace::mangle_unused_area_complete

Reviewed-by: tschatzl

! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp
! src/hotspot/share/gc/parallel/mutableNUMASpace.hpp
! src/hotspot/share/gc/parallel/mutableSpace.cpp
! src/hotspot/share/gc/parallel/mutableSpace.hpp

Changeset: 230fac80
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-05-08 17:57:46 +0000
URL:       https://git.openjdk.org/leyden/commit/230fac80f25e9608006c8928a8a7708bf13a818c

8331941: Make CollectedHeap::parallel_object_iterator public

Reviewed-by: tschatzl

! src/hotspot/share/gc/shared/collectedHeap.hpp

Changeset: 42b1d858
Author:    Ashutosh Mehra <asmehra at openjdk.org>
Date:      2024-05-08 20:26:02 +0000
URL:       https://git.openjdk.org/leyden/commit/42b1d858d15fd06de9ce41b08b430b12724652e9

8330275: Crash in XMark::follow_array

Reviewed-by: stefank, stuefe

! src/hotspot/cpu/aarch64/gc/x/xGlobals_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/z/zAddress_aarch64.cpp

Changeset: 0d1216c7
Author:    Erik Joelsson <erikj at openjdk.org>
Date:      2024-05-08 21:57:44 +0000
URL:       https://git.openjdk.org/leyden/commit/0d1216c7a1dc215550ac769afc21dea91c638215

8331939: Add custom hook for TestImage

Reviewed-by: mikael

! make/TestImage.gmk

Changeset: 588e314e
Author:    Erik Joelsson <erikj at openjdk.org>
Date:      2024-05-08 21:57:55 +0000
URL:       https://git.openjdk.org/leyden/commit/588e314e4b96f2a48d46ab8a088a7b8d26be318d

8331886: Allow markdown src file overrides

Reviewed-by: ihse

! make/Docs.gmk
! make/common/ProcessMarkdown.gmk

Changeset: 2d622152
Author:    Vladimir Petko <vpetko at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-05-08 22:36:25 +0000
URL:       https://git.openjdk.org/leyden/commit/2d622152b07bba0aba8fd5b1e24293e28d6e69f5

8331541: [i386] linking with libjvm.so fails after JDK-8283326

Reviewed-by: djelinski, ihse

! make/autoconf/flags-ldflags.m4
! src/hotspot/os_cpu/linux_x86/safefetch_linux_x86_32.S

Changeset: 964d6089
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-05-09 07:05:18 +0000
URL:       https://git.openjdk.org/leyden/commit/964d60892eec5e64942b49182a4c6d4105620acd

8322753: RISC-V: C2 ReverseBytesV

Reviewed-by: fyang

! src/hotspot/cpu/riscv/assembler_riscv.hpp
! src/hotspot/cpu/riscv/riscv_v.ad
! test/hotspot/jtreg/compiler/vectorapi/VectorReverseBytesTest.java
! test/hotspot/jtreg/compiler/vectorization/TestReverseBytes.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicCharOpTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicShortOpTest.java

Changeset: ac86f59e
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2024-05-09 07:43:03 +0000
URL:       https://git.openjdk.org/leyden/commit/ac86f59e4f5382d5c3e8984532dd210611db7dcb

8330532: Improve line-oriented text parsing in HotSpot

Co-authored-by: John R Rose <jrose at openjdk.org>
Reviewed-by: matsaave, jsjolen

! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/cds/classListParser.hpp
! src/hotspot/share/compiler/compilerOracle.cpp
! src/hotspot/share/compiler/compilerOracle.hpp
+ src/hotspot/share/utilities/istream.cpp
+ src/hotspot/share/utilities/istream.hpp
! src/hotspot/share/utilities/ostream.cpp
! src/hotspot/share/utilities/ostream.hpp
+ test/hotspot/gtest/utilities/test_istream.cpp
! test/hotspot/jtreg/runtime/cds/appcds/LongClassListPath.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassListFormatA.java

Changeset: ad0b54d4
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-05-09 11:47:45 +0000
URL:       https://git.openjdk.org/leyden/commit/ad0b54d429fdbd806c09aa06bb42f1ed4a0297e8

8314225: SIGSEGV in JavaThread::is_lock_owned

Reviewed-by: dlong, dholmes

! src/hotspot/share/jfr/leakprofiler/checkpoint/rootResolver.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/monitorChunk.cpp
! src/hotspot/share/runtime/monitorChunk.hpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/vframeArray.cpp
! src/hotspot/share/runtime/vframeArray.hpp

Changeset: 0a4eeeaa
Author:    Scott Gibbons <sgibbons at openjdk.org>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
Date:      2024-05-09 11:57:44 +0000
URL:       https://git.openjdk.org/leyden/commit/0a4eeeaa3c63585244be959386dd94882398e87f

8331033: EA fails with "EA unexpected CallLeaf unsafe_setmemory" after JDK-8329331

Co-authored-by: Jatin Bhateja <jbhateja at openjdk.org>
Reviewed-by: kvn

! src/hotspot/share/opto/escape.cpp
+ test/hotspot/jtreg/compiler/escapeAnalysis/Test8331033.java

Changeset: aaa90b30
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-05-09 13:54:04 +0000
URL:       https://git.openjdk.org/leyden/commit/aaa90b3005c85852971203ce6feb88e7091e167b

8327476: Upgrade JLine to 3.26.1

Reviewed-by: ihse, vromero

! make/conf/module-loader-map.conf
- make/modules/jdk.internal.le/Lib.gmk
- src/jdk.internal.le/aix/classes/jdk/internal/org/jline/terminal/impl/jna/JDKNativePty.java
- src/jdk.internal.le/linux/classes/jdk/internal/org/jline/terminal/impl/jna/JDKNativePty.java
- src/jdk.internal.le/linux/classes/jdk/internal/org/jline/terminal/impl/jna/linux/CLibrary.java
- src/jdk.internal.le/linux/classes/jdk/internal/org/jline/terminal/impl/jna/linux/CLibraryImpl.java
- src/jdk.internal.le/linux/classes/jdk/internal/org/jline/terminal/impl/jna/linux/LinuxNativePty.java
- src/jdk.internal.le/linux/classes/jdk/internal/org/jline/terminal/impl/jna/linux/UtilLibraryImpl.java
- src/jdk.internal.le/linux/native/lible/CLibrary.cpp
- src/jdk.internal.le/macosx/classes/jdk/internal/org/jline/terminal/impl/jna/JDKNativePty.java
- src/jdk.internal.le/macosx/classes/jdk/internal/org/jline/terminal/impl/jna/osx/CLibrary.java
- src/jdk.internal.le/macosx/classes/jdk/internal/org/jline/terminal/impl/jna/osx/CLibraryImpl.java
- src/jdk.internal.le/macosx/classes/jdk/internal/org/jline/terminal/impl/jna/osx/NativeLong.java
- src/jdk.internal.le/macosx/classes/jdk/internal/org/jline/terminal/impl/jna/osx/OsXNativePty.java
- src/jdk.internal.le/macosx/native/lible/CLibrary.cpp
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/keymap/BindingReader.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/keymap/KeyMap.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/Binding.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/Buffer.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/Candidate.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/Completer.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/CompletingParsedLine.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/CompletionMatcher.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/EOFError.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/Editor.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/EndOfFileException.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/Expander.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/Highlighter.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/History.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/LineReader.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/LineReaderBuilder.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/Macro.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/MaskingCallback.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/ParsedLine.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/Parser.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/PrintAboveWriter.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/Reference.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/SyntaxError.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/UserInterruptException.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/Widget.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/BufferImpl.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/CompletionMatcherImpl.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/DefaultExpander.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/DefaultHighlighter.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/DefaultParser.java
+ src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/InputRC.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/KillRing.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/LineReaderImpl.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/ReaderUtils.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/SimpleMaskingCallback.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/UndoTree.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/completer/AggregateCompleter.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/completer/ArgumentCompleter.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/completer/EnumCompleter.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/completer/FileNameCompleter.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/completer/NullCompleter.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/completer/StringsCompleter.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/completer/SystemCompleter.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/history/DefaultHistory.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/Attributes.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/Cursor.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/MouseEvent.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/Size.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/Terminal.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/TerminalBuilder.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractPosixTerminal.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractPty.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractTerminal.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractWindowsConsoleWriter.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractWindowsTerminal.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/CursorSupport.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/Diag.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/DumbTerminal.java
+ src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/DumbTerminalProvider.java
- src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ExecPty.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ExternalTerminal.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/LineDisciplineTerminal.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/MouseSupport.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/NativeSignalHandler.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/PosixPtyTerminal.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/PosixSysTerminal.java
+ src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/exec/ExecPty.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/exec/ExecTerminalProvider.java
+ src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/CLibrary.java
+ src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/FfmNativePty.java
+ src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/FfmTerminalProvider.java
+ src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java
+ src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/NativeWinConsoleWriter.java
+ src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/NativeWinSysTerminal.java
+ src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/WindowsAnsiWriter.java
- src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/jna/LastErrorException.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/spi/Pty.java
+ src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/spi/SystemStream.java
+ src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/spi/TerminalExt.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/spi/TerminalProvider.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/AnsiWriter.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/AttributedCharSequence.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/AttributedString.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/AttributedStringBuilder.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/AttributedStyle.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/ClosedException.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/ColorPalette.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/Colors.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/Curses.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/DiffHelper.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/Display.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/ExecHelper.java
+ src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/FastBufferedOutputStream.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/InfoCmp.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/InputStreamReader.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/Levenshtein.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/Log.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlocking.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlockingInputStream.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlockingInputStreamImpl.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlockingPumpInputStream.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlockingPumpReader.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlockingReader.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlockingReaderImpl.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/PumpReader.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/ShutdownHooks.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/Signals.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/Status.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/StyleResolver.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/Timeout.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/WCWidth.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/WriterOutputStream.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/windows-conemu.caps
! src/jdk.internal.le/share/legal/jline.md
- src/jdk.internal.le/unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java
- src/jdk.internal.le/unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java
- src/jdk.internal.le/windows/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java
- src/jdk.internal.le/windows/classes/jdk/internal/org/jline/terminal/impl/jna/win/IntByReference.java
- src/jdk.internal.le/windows/classes/jdk/internal/org/jline/terminal/impl/jna/win/JnaWinConsoleWriter.java
- src/jdk.internal.le/windows/classes/jdk/internal/org/jline/terminal/impl/jna/win/JnaWinSysTerminal.java
- src/jdk.internal.le/windows/classes/jdk/internal/org/jline/terminal/impl/jna/win/Kernel32.java
- src/jdk.internal.le/windows/classes/jdk/internal/org/jline/terminal/impl/jna/win/Kernel32Impl.java
- src/jdk.internal.le/windows/classes/jdk/internal/org/jline/terminal/impl/jna/win/Pointer.java
- src/jdk.internal.le/windows/classes/jdk/internal/org/jline/terminal/impl/jna/win/WindowsAnsiWriter.java
- src/jdk.internal.le/windows/native/lible/Kernel32.cpp
! test/jdk/jdk/internal/jline/AbstractWindowsTerminalTest.java
! test/jdk/jdk/internal/jline/KeyConversionTest.java
! test/langtools/jdk/jshell/ExecPtyGetFlagsToSetTest.java

Changeset: c4ff58b9
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2024-05-09 14:30:15 +0000
URL:       https://git.openjdk.org/leyden/commit/c4ff58b9bcfd08eae0623a648a837e08f25b3f9b

8330146: assert(!_thread->is_in_any_VTMS_transition()) failed

Reviewed-by: cjplummer, kevinw

! src/hotspot/share/prims/jvmtiExport.cpp

Changeset: ba8bf2e7
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-05-09 13:56:20 +0000
URL:       https://git.openjdk.org/leyden/commit/ba8bf2e7cff42668aa3168f6623353320e7129b5

Merge branch 'master' of https://github.com/openjdk/leyden into premain

! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/cds/classListParser.hpp
! src/hotspot/share/cds/classListWriter.cpp
! src/hotspot/share/compiler/compilerOracle.cpp
! src/hotspot/share/compiler/compilerOracle.hpp
! src/hotspot/share/prims/jvmtiExport.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/utilities/ostream.cpp
! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/cds/classListParser.hpp
! src/hotspot/share/cds/classListWriter.cpp
! src/hotspot/share/compiler/compilerOracle.cpp
! src/hotspot/share/compiler/compilerOracle.hpp
! src/hotspot/share/prims/jvmtiExport.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/utilities/ostream.cpp


From duke at openjdk.org  Fri May 10 20:08:17 2024
From: duke at openjdk.org (duke)
Date: Fri, 10 May 2024 20:08:17 GMT
Subject: git: openjdk/leyden: premain: Fixed typo in
 test/hotspot/jtreg/premain/lib/build-for-jtreg.sh
Message-ID: <17895929-6659-489c-af0a-7cfc3e0c7e3b@openjdk.org>

Changeset: 49baa911
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-05-10 13:06:37 +0000
URL:       https://git.openjdk.org/leyden/commit/49baa911134e0e3c5a9f5128b30fa12c8bd33683

Fixed typo in test/hotspot/jtreg/premain/lib/build-for-jtreg.sh

! test/hotspot/jtreg/premain/lib/build-for-jtreg.sh


From duke at openjdk.org  Sat May 11 02:03:35 2024
From: duke at openjdk.org (duke)
Date: Sat, 11 May 2024 02:03:35 GMT
Subject: git: openjdk/leyden: premain: Remove restore_unshareable_info()
Message-ID: <e29a841b-e110-4faf-909f-350a7cd1ba2c@openjdk.org>

Changeset: 84afb72e
Author:    Igor Veresov <igor.veresov at oracle.com>
Date:      2024-05-10 19:02:15 +0000
URL:       https://git.openjdk.org/leyden/commit/84afb72eb2eef7e3f945a2816308d7ea2220c427

Remove restore_unshareable_info()

! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/oops/trainingData.cpp
! src/hotspot/share/oops/trainingData.hpp


From duke at openjdk.org  Mon May 13 22:42:43 2024
From: duke at openjdk.org (duke)
Date: Mon, 13 May 2024 22:42:43 GMT
Subject: git: openjdk/leyden: premain: Fixed _compare_premain_builds in
 test/hotspot/jtreg/premain/lib/Bench.gmk to be compatible with
 premain/spring-petclinic/Makefile
Message-ID: <1d3c811e-e036-4d27-855b-a296d2f5bc0c@openjdk.org>

Changeset: 86ec27a6
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-05-13 15:41:22 +0000
URL:       https://git.openjdk.org/leyden/commit/86ec27a6bccffc3c18b63dc21ddf9eada93b2943

Fixed _compare_premain_builds in test/hotspot/jtreg/premain/lib/Bench.gmk to be compatible with premain/spring-petclinic/Makefile

! test/hotspot/jtreg/premain/lib/Bench.gmk


From duke at openjdk.org  Wed May 15 08:33:41 2024
From: duke at openjdk.org (duke)
Date: Wed, 15 May 2024 08:33:41 GMT
Subject: git: openjdk/leyden: premain: support benchmarking for new workflow
Message-ID: <83e3c06f-9234-4be1-8a4b-70f448f98ee3@openjdk.org>

Changeset: f11f4604
Author:    Andrew Dinn <adinn at redhat.com>
Date:      2024-05-14 12:47:29 +0000
URL:       https://git.openjdk.org/leyden/commit/f11f4604c48d65ea05a30dd37b2ca3419643532c

support benchmarking for new workflow

tidy up and document extra caller options

! test/hotspot/jtreg/premain/javac_new_workflow/Makefile
+ test/hotspot/jtreg/premain/javac_new_workflow/run_bench.sh
+ test/hotspot/jtreg/premain/lib/bench-lib-new-workflow.sh


From duke at openjdk.org  Wed May 15 08:44:05 2024
From: duke at openjdk.org (duke)
Date: Wed, 15 May 2024 08:44:05 GMT
Subject: git: openjdk/leyden: premain: include missing TASKSET arg
Message-ID: <0c289071-8466-4183-856f-bbe9306a5fe6@openjdk.org>

Changeset: 9c7ef4ea
Author:    Andrew Dinn <adinn at redhat.com>
Date:      2024-05-15 08:41:18 +0000
URL:       https://git.openjdk.org/leyden/commit/9c7ef4ea439d7a2bae903cb0950b6f4afc7f6269

include missing TASKSET arg

! test/hotspot/jtreg/premain/lib/bench-lib-new-workflow.sh


From duke at openjdk.org  Wed May 15 21:28:39 2024
From: duke at openjdk.org (duke)
Date: Wed, 15 May 2024 21:28:39 GMT
Subject: git: openjdk/leyden: premain: Refactored applications/JavacBench.java
 test; added sanity validation
Message-ID: <ee478f76-f1b8-4e90-9c67-3af2b571821b@openjdk.org>

Changeset: b2e204aa
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-05-15 14:27:56 +0000
URL:       https://git.openjdk.org/leyden/commit/b2e204aaf16344b6507f39e5c71037f1ff71403e

Refactored applications/JavacBench.java test; added sanity validation

+ test/hotspot/jtreg/runtime/cds/appcds/applications/JavacBench.java
+ test/hotspot/jtreg/runtime/cds/appcds/applications/JavacBenchApp.java
- test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBench.java
- test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBenchApp.java
- test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBenchDynamic.java
- test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBenchLeyden.java
- test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBenchLeydenOldWF.java
- test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBenchStatic.java


From duke at openjdk.org  Thu May 16 03:29:07 2024
From: duke at openjdk.org (duke)
Date: Thu, 16 May 2024 03:29:07 GMT
Subject: git: openjdk/leyden: premain: 76 new changesets
Message-ID: <0657cba0-4a76-4a14-a62e-d858c2da7a64@openjdk.org>

Changeset: 3674fc32
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-05-13 20:19:37 +0000
URL:       https://git.openjdk.org/leyden/commit/3674fc32ec879c2d3fb1f7007e8e373b84108757

Clean up ClassListParser

! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/cds/classListParser.hpp
! src/hotspot/share/cds/metaspaceShared.cpp

Changeset: 06232a3c
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-05-15 12:37:40 +0000
URL:       https://git.openjdk.org/leyden/commit/06232a3cfcc5968ea9f08e89d4c57b7f68a61359

prepare for upstreaming JDK-8293980

! src/hotspot/share/cds/classPrelinker.cpp
! src/hotspot/share/cds/regeneratedClasses.cpp
! src/hotspot/share/cds/regeneratedClasses.hpp

Changeset: aa4cddd4
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-05-09 15:42:41 +0000
URL:       https://git.openjdk.org/leyden/commit/aa4cddd4b8a6a12ba5d0360a721aebaabf362fff

8331950: Remove MemoryPoolMBean/isCollectionUsageThresholdExceeded from ZGC ProblemLists

Reviewed-by: sspitsyn

! test/hotspot/jtreg/ProblemList-generational-zgc.txt
! test/hotspot/jtreg/ProblemList-zgc.txt

Changeset: c7d98df2
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-05-09 15:54:25 +0000
URL:       https://git.openjdk.org/leyden/commit/c7d98df2ac509ebc8f4e801a0874a9497c54c602

8329691: Support `nonlikelyScript` parent locale inheritance

Reviewed-by: joehw

! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java
! make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java
! make/jdk/src/classes/build/tools/cldrconverter/SupplementalDataParseHandler.java
! src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java
+ test/jdk/sun/util/locale/provider/NonLikelyScriptTest.java

Changeset: ffbdfffb
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-05-09 18:01:27 +0000
URL:       https://git.openjdk.org/leyden/commit/ffbdfffbc702253f32fa45dc1855b663c72074a6

8331999: BasicDirectoryModel/LoaderThreadCount.java frequently fails on Windows in CI

Introduce tolerance factor: count > loaderCount.size() / 2
Fail the test only if the number of snapshots with more than
2 file loader threads is greater than half of the number
of valid snapshots.

Reviewed-by: prr, honkar

! test/jdk/javax/swing/plaf/basic/BasicDirectoryModel/LoaderThreadCount.java

Changeset: 0bf72821
Author:    Mikhailo Seledtsov <mseledtsov at openjdk.org>
Date:      2024-05-09 22:53:10 +0000
URL:       https://git.openjdk.org/leyden/commit/0bf728212fb4bce067076780aaa5b9341d7cdb6b

8331231: containers/docker/TestContainerInfo.java fails

Reviewed-by: dholmes

! test/hotspot/jtreg/containers/docker/TestContainerInfo.java

Changeset: d47a4e9f
Author:    Zhao Song <zsong at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
Date:      2024-05-09 23:05:05 +0000
URL:       https://git.openjdk.org/leyden/commit/d47a4e9f63a9414b90e09514bc26f6f7142ad49f

8332008: Enable issuestitle check

Reviewed-by: erikj

! .jcheck/conf

Changeset: a643d6c7
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-05-09 23:37:45 +0000
URL:       https://git.openjdk.org/leyden/commit/a643d6c7ac8a7bc0d3a288c1ef3f07876cf70590

8331862: Remove split relocation info implementation

Reviewed-by: dlong

! src/hotspot/cpu/aarch64/relocInfo_aarch64.cpp
! src/hotspot/cpu/arm/relocInfo_arm.cpp
! src/hotspot/cpu/ppc/relocInfo_ppc.cpp
! src/hotspot/cpu/riscv/relocInfo_riscv.cpp
! src/hotspot/cpu/s390/assembler_s390.hpp
! src/hotspot/cpu/s390/relocInfo_s390.cpp
! src/hotspot/cpu/x86/relocInfo_x86.cpp
! src/hotspot/cpu/zero/relocInfo_zero.cpp
! src/hotspot/share/code/relocInfo.cpp
! src/hotspot/share/code/relocInfo.hpp

Changeset: a706ca4f
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-05-10 01:34:02 +0000
URL:       https://git.openjdk.org/leyden/commit/a706ca4fdb4db4ba36c6ad04a37c37a348f8af0b

8329418: Replace pointers to tables with offsets in relocation bitmap

Reviewed-by: cjplummer, iklam

! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/archiveBuilder.hpp
! src/hotspot/share/cds/archiveUtils.cpp
! src/hotspot/share/cds/archiveUtils.hpp
! src/hotspot/share/cds/cppVtables.cpp
! src/hotspot/share/cds/cppVtables.hpp
! src/hotspot/share/cds/dynamicArchive.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/cds/serializeClosure.hpp
! src/hotspot/share/classfile/vmSymbols.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FileMapInfo.java

Changeset: d2d37c91
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-05-10 04:30:17 +0000
URL:       https://git.openjdk.org/leyden/commit/d2d37c913e5b55f7aec2c7a6b5a2328348ded223

8331942: On Linux aarch64, CDS archives should be using 64K alignment by default

Reviewed-by: aph, iklam

! make/autoconf/jdk-options.m4

Changeset: b9a142a2
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Date:      2024-05-10 04:45:01 +0000
URL:       https://git.openjdk.org/leyden/commit/b9a142a2243676b3f4fe288e7a28f4957a4d1edd

8226990: GTK & Nimbus LAF: Tabbed pane's background color is not expected one when change the opaque checkbox.

Reviewed-by: tr, honkar, psadhukhan

! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java
! src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf
! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java
+ test/jdk/javax/swing/JTabbedPane/TestJTabbedPaneOpaqueColor.java

Changeset: f47fc867
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-05-10 06:25:38 +0000
URL:       https://git.openjdk.org/leyden/commit/f47fc867b3518cb285d39f7b157bf7fde87b2083

8331908: Simplify log code in vectorintrinsics.cpp

Reviewed-by: jwaters, kvn

! src/hotspot/share/opto/vectorIntrinsics.cpp

Changeset: 7db6a3f0
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-05-10 07:58:20 +0000
URL:       https://git.openjdk.org/leyden/commit/7db6a3f0ee3986b492786bec99b207ec36401c57

8331905: Fix direct includes of g1_globals.hpp

Reviewed-by: ayang, tschatzl, gli

! src/hotspot/share/gc/g1/g1CollectionSetCandidates.hpp
! src/hotspot/share/gc/g1/g1ConcurrentRebuildAndScrub.cpp
! src/hotspot/share/gc/g1/g1MonotonicArenaFreeMemoryTask.cpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.hpp
! src/hotspot/share/gc/g1/g1RemSet.cpp
! src/hotspot/share/gc/g1/g1YoungCollector.cpp
! src/hotspot/share/gc/g1/g1YoungGCAllocationFailureInjector.cpp
! src/hotspot/share/gc/g1/g1YoungGCAllocationFailureInjector.hpp
! src/hotspot/share/gc/g1/g1YoungGCAllocationFailureInjector.inline.hpp

Changeset: d6541245
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-05-10 08:22:46 +0000
URL:       https://git.openjdk.org/leyden/commit/d65412450254992c05c851298323b6acd3b39bd3

8331932: Startup regressions in 23-b13

Reviewed-by: alanb, naoto, liach

! src/java.base/share/classes/java/util/Locale.java
! src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java
! src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java
! src/java.base/share/classes/sun/util/locale/BaseLocale.java

Changeset: 9f43ce5a
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-05-10 09:48:14 +0000
URL:       https://git.openjdk.org/leyden/commit/9f43ce5a725b212cec0f3cd17491c4bada953676

8330027: Identity hashes of archived objects must be based on a reproducible random seed

Reviewed-by: ccheung, iklam

! src/hotspot/share/cds/archiveHeapWriter.cpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/runtime/thread.cpp

Changeset: dab92c51
Author:    ?? <jinguojie.jgj at alibaba-inc.com>
Committer: Eric Liu <eliu at openjdk.org>
Date:      2024-05-10 10:01:40 +0000
URL:       https://git.openjdk.org/leyden/commit/dab92c51c70767abcda3b1a91dd7d1a9b40290c1

8331558: AArch64: optimize integer remainder

Reviewed-by: eliu, aph

! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp
! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp

Changeset: dea8076a
Author:    SendaoYan <syan at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
Date:      2024-05-10 10:10:53 +0000
URL:       https://git.openjdk.org/leyden/commit/dea8076a584fcb41d1b911af911605e2e7f82a87

8332006: Test com/sun/net/httpserver/TcpNoDelayNotRequired.java run timeout with -Xcomp

Reviewed-by: jpai, dfuchs

! test/jdk/com/sun/net/httpserver/TcpNoDelayNotRequired.java

Changeset: 784b8fce
Author:    Chen Liang <liach at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
Date:      2024-05-10 10:50:51 +0000
URL:       https://git.openjdk.org/leyden/commit/784b8fce7a1b05209a8db168c8d2f86484a1a817

8331744: java.lang.classfile.TypeKind improvements

Reviewed-by: asotona, redestad

! src/java.base/share/classes/java/lang/classfile/TypeKind.java
! src/java.base/share/classes/java/lang/classfile/instruction/NewPrimitiveArrayInstruction.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java
+ test/jdk/jdk/classfile/TypeKindTest.java
+ test/micro/org/openjdk/bench/java/lang/classfile/TypeKindBench.java

Changeset: 1547a696
Author:    Tejesh R <tr at openjdk.org>
Date:      2024-05-10 11:26:12 +0000
URL:       https://git.openjdk.org/leyden/commit/1547a696512b03ccc950b17f201ddca83f5016ec

8327696: [TESTBUG] "javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java" test instruction needs to be corrected

Reviewed-by: abhiscxk, honkar

! test/jdk/javax/swing/JTable/KeyBoardNavigation.java

Changeset: 45792c58
Author:    Jan Kratochvil <jkratochvil at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
Date:      2024-05-10 12:16:47 +0000
URL:       https://git.openjdk.org/leyden/commit/45792c5829fb1d5ee016c4a1fd6badb5d2b4239c

8331352: error: template-id not allowed for constructor/destructor in C++20

Reviewed-by: kbarrett, stefank

! src/hotspot/share/gc/z/zArray.inline.hpp
! src/hotspot/share/utilities/chunkedList.hpp
! src/hotspot/share/utilities/events.hpp
! src/hotspot/share/utilities/linkedlist.hpp

Changeset: 242446b0
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-05-10 12:30:05 +0000
URL:       https://git.openjdk.org/leyden/commit/242446b07fcfcac136510495d1ff16d26859aea4

8331931: JFR: Avoid loading regex classes during startup

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java

Changeset: 675fbe69
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-05-10 13:57:55 +0000
URL:       https://git.openjdk.org/leyden/commit/675fbe699ed1aad37f34429cbe1f4f3e029be03f

8331993: Add counting leading/trailing zero tests for Integer

Reviewed-by: chagedorn

! test/hotspot/jtreg/compiler/c2/irTests/TestDisableAutoVectOpcodes.java
! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java
! test/hotspot/jtreg/compiler/vectorization/TestNumberOfContinuousZeros.java

Changeset: f95c9374
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-05-10 13:59:09 +0000
URL:       https://git.openjdk.org/leyden/commit/f95c93740538e5e508407ec6750ed9f126fdc3c3

8331577: RISC-V: C2 CountLeadingZerosV
8331578: RISC-V: C2 CountTrailingZerosV

Reviewed-by: fyang

! src/hotspot/cpu/riscv/assembler_riscv.hpp
! src/hotspot/cpu/riscv/riscv_v.ad
! test/hotspot/jtreg/compiler/vectorization/TestNumberOfContinuousZeros.java

Changeset: d11e70ad
Author:    Serhiy Sachkov <serhiy.sachkov at oracle.com>
Committer: Mahendra Chhipa <mchhipa at openjdk.org>
Date:      2024-05-10 14:59:26 +0000
URL:       https://git.openjdk.org/leyden/commit/d11e70ade3e9094c8bef0074c736215d48d47a2a

8331646: Add specific regression leap year tests

Reviewed-by: naoto

+ test/jdk/java/util/Calendar/CalendarLeapYearAddTest.java

Changeset: d215bc46
Author:    Andrew Haley <aph at openjdk.org>
Date:      2024-05-10 15:06:21 +0000
URL:       https://git.openjdk.org/leyden/commit/d215bc46475b90abd898e995c1b4a6aa4b6cb024

8332066: AArch64: Math test failures since JDK-8331558

Reviewed-by: kvn

! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp
! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp

Changeset: 65abf24f
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-05-10 16:10:40 +0000
URL:       https://git.openjdk.org/leyden/commit/65abf24fde6432fb386a616bbadc5689975c3bf4

8331866: Add warnings for locale data dependence

Reviewed-by: jlu, srl, joehw

! src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java

Changeset: 1c5f1501
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-05-10 16:22:28 +0000
URL:       https://git.openjdk.org/leyden/commit/1c5f1501ac4ef55ca6ffaaa0576de9b0e1dd8d06

8331734: Atomic MemorySegment VarHandle operations fails for element layouts

Reviewed-by: pminborg, psandoz

! src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java
! test/jdk/java/foreign/TestAccessModes.java
! test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNonConstant.java

Changeset: 1b476f52
Author:    Valerie Peng <valeriep at openjdk.org>
Date:      2024-05-10 16:53:27 +0000
URL:       https://git.openjdk.org/leyden/commit/1b476f52ba85f9ceaabe785d36cb07df831fd0e8

8293345: SunPKCS11 provider checks on PKCS11 Mechanism are problematic

Reviewed-by: djelinski, weijun

! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java
! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java

Changeset: 5e8e8ef6
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2024-05-10 20:34:17 +0000
URL:       https://git.openjdk.org/leyden/commit/5e8e8ef6565e82a23626fe16893f93870dae1012

8315431: ArchiveHeapWriter::get_filler_size_at() cannot handle buffer expansion

Reviewed-by: matsaave, ccheung

! src/hotspot/share/cds/archiveHeapWriter.cpp

Changeset: 1dac34fa
Author:    Roman Kennke <rkennke at openjdk.org>
Date:      2024-05-10 21:13:43 +0000
URL:       https://git.openjdk.org/leyden/commit/1dac34fa757f1d603f0bc9b9c1994c114c276add

8331098: [Aarch64] Fix crash in Arrays.equals() intrinsic with -CCP

Reviewed-by: aboldtch, aph

! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp

Changeset: b87a7e99
Author:    Nizar Benalla <nizar.benalla at oracle.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
Date:      2024-05-11 04:24:48 +0000
URL:       https://git.openjdk.org/leyden/commit/b87a7e990631c8b402578f645397b2aeda8927bb

8144100: Incorrect case-sensitive equality in com.sun.net.httpserver.BasicAuthenticator

Reviewed-by: jpai, dfuchs

! src/jdk.httpserver/share/classes/com/sun/net/httpserver/BasicAuthenticator.java
+ test/jdk/com/sun/net/httpserver/BasicAuthToken.java

Changeset: f9a1d338
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-05-11 04:31:11 +0000
URL:       https://git.openjdk.org/leyden/commit/f9a1d3381b12c97784c11649be079147c85939c0

8332020: jwebserver tool prints invalid URL in case of IPv6 address binding

Reviewed-by: dfuchs, vtewari

! src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/SimpleFileServerImpl.java
+ test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/IPv6BoundHost.java

Changeset: 32c7681c
Author:    Alan Bateman <alanb at openjdk.org>
Date:      2024-05-11 07:36:52 +0000
URL:       https://git.openjdk.org/leyden/commit/32c7681cf310c87669c502c4a8b62a7fecc93360

8332029: Provide access to initial value of stderr via JavaLangAccess

Reviewed-by: jpai, bpb, mcimadamore

! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/share/classes/jdk/internal/misc/VM.java

Changeset: 5053b70a
Author:    Viktor Klang <vklang at openjdk.org>
Date:      2024-05-11 18:37:43 +0000
URL:       https://git.openjdk.org/leyden/commit/5053b70a7fc67ce9b73dbeecbdd88fbc34d45e04

8278255: Add more warning text in ReentrantLock and ReentrantReadWriteLock

Reviewed-by: prappo, alanb

! src/java.base/share/classes/java/util/concurrent/locks/Lock.java
! src/java.base/share/classes/java/util/concurrent/locks/ReentrantLock.java
! src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java

Changeset: d517d2df
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-05-13 05:45:36 +0000
URL:       https://git.openjdk.org/leyden/commit/d517d2df451e135583083ed3684d7d3241b36f76

8331764: C2 SuperWord: refactor _align_to_ref/_mem_ref_for_main_loop_alignment

Reviewed-by: kvn, chagedorn

! src/hotspot/share/opto/superword.cpp
! src/hotspot/share/opto/superword.hpp

Changeset: 3e3f7cf4
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Date:      2024-05-13 07:33:42 +0000
URL:       https://git.openjdk.org/leyden/commit/3e3f7cf4bddf243fddfeac8cfc1d9b2a1be55043

8330387: Crash with a different types patterns (primitive vs generic) in instanceof

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
! test/langtools/tools/javac/patterns/PrimitiveInstanceOfPatternOpWithRecordPatterns.java
! test/langtools/tools/javac/patterns/PrimitiveInstanceOfPatternOpWithTopLevelPatterns.java
! test/langtools/tools/javac/patterns/PrimitiveInstanceOfTypeComparisonOp.java
! test/langtools/tools/javac/patterns/PrimitivePatternsSwitchErrors.java
! test/langtools/tools/javac/patterns/PrimitivePatternsSwitchErrors.out

Changeset: 5a8df410
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-05-13 08:16:30 +0000
URL:       https://git.openjdk.org/leyden/commit/5a8df4106ac5386eb72e874dcadf2b18defe27d8

8331535: Incorrect prompt for Console.readLine
8331681: Test that jdk.internal.io.JdkConsole does not interpret prompts

Reviewed-by: naoto, asotona

! src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java
+ test/jdk/java/io/Console/ConsolePromptTest.java
+ test/jdk/jdk/internal/jline/JLineConsoleProviderTest.java
+ test/langtools/jdk/jshell/ConsoleToolTest.java
! test/langtools/jdk/jshell/ReplToolTesting.java

Changeset: adaa509b
Author:    Chen Liang <liach at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
Date:      2024-05-13 09:11:49 +0000
URL:       https://git.openjdk.org/leyden/commit/adaa509b6ed3d12569b8e5f2ec802cef22ab53c7

8327499: MethodHandleStatics.traceLambdaForm includes methods that cannot be generated

Reviewed-by: redestad, iklam

! src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java
! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/CDSLambdaInvoker.java
! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestLambdaInvokers.java
! test/jdk/tools/jlink/plugins/GenerateJLIClassesPluginTest.java
! test/jdk/tools/lib/tests/JImageValidator.java

Changeset: 391bbbc7
Author:    Tobias Holenstein <tholenstein at openjdk.org>
Date:      2024-05-13 09:14:17 +0000
URL:       https://git.openjdk.org/leyden/commit/391bbbc7d0fb95b0cd55e2f56c43bee019aeab7f

8330584: IGV: XML does not save all node properties

Reviewed-by: rcastanedalo, chagedorn

! src/utils/IdealGraphVisualizer/Coordinator/src/main/java/com/sun/hotspot/igv/coordinator/OutlineTopComponent.java
! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/InputNode.java
! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/serialization/Printer.java

Changeset: 1484153c
Author:    Hannes Walln?fer <hannesw at openjdk.org>
Date:      2024-05-13 09:48:23 +0000
URL:       https://git.openjdk.org/leyden/commit/1484153c1a092cefc20270b35aa1e508280843a4

8332080: Update troff man page for javadoc

Reviewed-by: jjg

! src/jdk.javadoc/share/man/javadoc.1
! test/langtools/jdk/javadoc/tool/CheckManPageOptions.java

Changeset: abf54bb1
Author:    Nizar Benalla <nizar.benalla at oracle.com>
Committer: Sean Mullan <mullan at openjdk.org>
Date:      2024-05-13 13:01:15 +0000
URL:       https://git.openjdk.org/leyden/commit/abf54bb1e6da6d7bc432b3e9bb3ff164a895bd3e

8332100: Add missing `@since` to KeyValue::EC_TYPE in `java.xml.crypto`

Reviewed-by: mullan

! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/keyinfo/KeyValue.java

Changeset: ff4bf1cf
Author:    Nizar Benalla <nizar.benalla at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
Date:      2024-05-13 13:49:01 +0000
URL:       https://git.openjdk.org/leyden/commit/ff4bf1cf9f18547cff8f484433c3c55b4c288aaa

8332102: Add `@since` to package-info of `jdk.security.jarsigner`

Reviewed-by: weijun

! src/jdk.jartool/share/classes/jdk/security/jarsigner/package-info.java

Changeset: 7c2c24fc
Author:    Prajwal Kumaraswamy <pkumaraswamy at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
Date:      2024-05-13 16:10:45 +0000
URL:       https://git.openjdk.org/leyden/commit/7c2c24fc0511b36132952c96be46eea5904a53c5

8261433: Better pkcs11 performance for libpkcs11:C_EncryptInit/libpkcs11:C_DecryptInit

Reviewed-by: djelinski, valeriep, coffeys

! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java
! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java
! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c
! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c
! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c

Changeset: 5ded8da6
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-05-13 16:49:48 +0000
URL:       https://git.openjdk.org/leyden/commit/5ded8da676d62158d0011086d7f80ff2c9096e13

8332085: Remove 10 year old transition check in GenerateCurrencyData tool

Reviewed-by: erikj, iris
Backport-of: 4f3b76ff496e7423e5c43ca62cef019e4f4292ec

! make/jdk/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java

Changeset: 440782e0
Author:    SendaoYan <syan at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2024-05-14 02:12:57 +0000
URL:       https://git.openjdk.org/leyden/commit/440782e0160f867f08afbec0abf48d557a522c72

8331466: Problemlist serviceability/dcmd/gc/RunFinalizationTest.java on generic-all

Reviewed-by: sspitsyn, cjplummer

! test/hotspot/jtreg/ProblemList.txt

Changeset: beea5305
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
Date:      2024-05-14 05:01:51 +0000
URL:       https://git.openjdk.org/leyden/commit/beea5305b071820e2b128a55c5ca384caf470fdd

8331907: BigInteger and BigDecimal should use optimized division

Reviewed-by: rgiulietti, bpb

! src/java.base/share/classes/java/math/BigDecimal.java
! src/java.base/share/classes/java/math/MutableBigInteger.java
! test/micro/org/openjdk/bench/java/math/BigDecimals.java
! test/micro/org/openjdk/bench/java/math/BigIntegers.java

Changeset: ea5eb74a
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Date:      2024-05-14 06:41:58 +0000
URL:       https://git.openjdk.org/leyden/commit/ea5eb74a65f20ce28fa0a94ea851915d4a6f83da

8326404: Assertion error when trying to compile switch with fallthrough with pattern

Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
+ test/langtools/tools/javac/patterns/T8326404.java

Changeset: 7ce4a13c
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-05-14 11:26:57 +0000
URL:       https://git.openjdk.org/leyden/commit/7ce4a13c0a891e606480e138f4025ffa328a18b3

8332130: RISC-V: remove wrong instructions of Vector Crypto Extension

Reviewed-by: luhenry, fyang

! src/hotspot/cpu/riscv/assembler_riscv.hpp

Changeset: 4ba74475
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2024-05-14 13:11:28 +0000
URL:       https://git.openjdk.org/leyden/commit/4ba74475d44831c1fe49359458163cd1567e9619

8326957: Implement JEP 474: ZGC: Generational Mode by Default

Reviewed-by: stefank, eosterlund

! src/hotspot/share/gc/shared/gc_globals.hpp
! src/hotspot/share/gc/x/xArguments.cpp
! src/hotspot/share/gc/x/xInitialize.cpp
! src/hotspot/share/runtime/arguments.cpp
+ test/hotspot/jtreg/gc/x/TestDeprecated.java
+ test/hotspot/jtreg/gc/z/TestDefault.java
! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java

Changeset: 5a4415a6
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
Committer: Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-05-14 14:04:28 +0000
URL:       https://git.openjdk.org/leyden/commit/5a4415a6bddb25cbd5b87ff8ad1a06179c2e452e

8331858: [nmt] VM.native_memory statistics should work in summary mode

Reviewed-by: stuefe, jsjolen

! src/hotspot/share/nmt/memTracker.cpp
! src/hotspot/share/nmt/nmtDCmd.cpp
+ test/hotspot/jtreg/runtime/NMT/JcmdSummaryStatistics.java

Changeset: 95a60131
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-05-14 14:58:51 +0000
URL:       https://git.openjdk.org/leyden/commit/95a601316de06b4b0fbf6e3c7777be5d2a1ca978

8332042: Move MEMFLAGS to its own include file

Reviewed-by: jsjolen, stefank

! src/hotspot/share/gc/g1/g1MonotonicArena.hpp
! src/hotspot/share/gc/shared/oopStorageSet.hpp
! src/hotspot/share/gc/shared/stringdedup/stringDedupProcessor.cpp
! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp
! src/hotspot/share/gc/z/zNMT.cpp
! src/hotspot/share/jfr/leakprofiler/chains/jfrbitset.hpp
! src/hotspot/share/jfr/periodic/jfrNativeMemoryEvent.hpp
! src/hotspot/share/memory/allocation.hpp
! src/hotspot/share/memory/guardedMemory.cpp
! src/hotspot/share/memory/padded.hpp
! src/hotspot/share/nmt/allocationSite.hpp
! src/hotspot/share/nmt/mallocHeader.cpp
! src/hotspot/share/nmt/mallocHeader.hpp
! src/hotspot/share/nmt/mallocTracker.hpp
! src/hotspot/share/nmt/memFlagBitmap.hpp
! src/hotspot/share/nmt/memMapPrinter.cpp
! src/hotspot/share/nmt/memMapPrinter.hpp
! src/hotspot/share/nmt/memReporter.cpp
+ src/hotspot/share/nmt/memflags.hpp
! src/hotspot/share/nmt/nmtCommon.hpp
! src/hotspot/share/prims/jvmtiAgentList.hpp
! src/hotspot/share/services/mallocLimit.cpp
! src/hotspot/share/services/mallocLimit.hpp
! src/hotspot/share/services/threadService.cpp
! src/hotspot/share/utilities/bitMap.hpp

Changeset: e91492ab
Author:    Inigo Mediavilla Saiz <imediava at gmail.com>
Committer: Brian Burkhalter <bpb at openjdk.org>
Date:      2024-05-14 16:04:34 +0000
URL:       https://git.openjdk.org/leyden/commit/e91492ab4333c61f39b50eb428fa932131a5b908

8313674: (fc) java/nio/channels/FileChannel/BlockDeviceSize.java should test for more block devices

Reviewed-by: alanb, bpb

! test/jdk/java/nio/channels/FileChannel/BlockDeviceSize.java

Changeset: 4d32c607
Author:    Calvin Cheung <ccheung at openjdk.org>
Date:      2024-05-14 19:21:51 +0000
URL:       https://git.openjdk.org/leyden/commit/4d32c607a4b496bf2bb09e54167ecbbab5569a0c

8322008: Exclude some CDS tests from running with -Xshare:off

Reviewed-by: lmesnik, iklam

! test/hotspot/jtreg/TEST.groups

Changeset: 0bb5ae64
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-05-14 20:17:01 +0000
URL:       https://git.openjdk.org/leyden/commit/0bb5ae645165b97527ecccf02308df6072c363d8

8332248: (fc) java/nio/channels/FileChannel/BlockDeviceSize.java failed with RuntimeException

Reviewed-by: alanb

! test/jdk/java/nio/channels/FileChannel/BlockDeviceSize.java

Changeset: 7b4ba7f9
Author:    Julian Waters <jwaters at openjdk.org>
Date:      2024-05-15 00:23:26 +0000
URL:       https://git.openjdk.org/leyden/commit/7b4ba7f90ab9ea5e1070c79534c587dad17d1bdd

8325932: Replace ATTRIBUTE_NORETURN with direct [[noreturn]]

Reviewed-by: kbarrett, dholmes

! src/hotspot/share/runtime/os.hpp
- src/hotspot/share/utilities/attributeNoreturn.hpp
! src/hotspot/share/utilities/debug.hpp
! src/hotspot/share/utilities/globalDefinitions.hpp
! src/hotspot/share/utilities/vmError.hpp

Changeset: 4e77cf88
Author:    Cesar Soares Lucas <cslucas at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-05-15 01:46:22 +0000
URL:       https://git.openjdk.org/leyden/commit/4e77cf881d031e5b0320915b3eabd7702e560291

8330795: C2: assert((uint)type <= T_CONFLICT && _zero_type[type] != nullptr) failed: bad type with -XX:-UseCompressedClassPointers

Reviewed-by: kvn

! src/hotspot/share/opto/escape.cpp
+ test/hotspot/jtreg/compiler/c2/TestReduceAllocationAndLoadKlass.java
! test/hotspot/jtreg/compiler/c2/irTests/scalarReplacement/AllocationMergesTests.java

Changeset: d04ac14b
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-05-15 05:43:18 +0000
URL:       https://git.openjdk.org/leyden/commit/d04ac14bdbab4187d0be98b8471f90be8a14f649

8332236: javac crashes with module imports and implicitly declared class

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! test/langtools/tools/javac/ImportModule.java

Changeset: c642f44b
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2024-05-15 06:05:23 +0000
URL:       https://git.openjdk.org/leyden/commit/c642f44bbe1e4cdbc23496a34ddaae30990ce7c0

8329839: Cleanup ZPhysicalMemoryBacking trace logging

Reviewed-by: stefank, ayang

! src/hotspot/os/bsd/gc/z/zPhysicalMemoryBacking_bsd.cpp
! src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp
! src/hotspot/os/windows/gc/z/zPhysicalMemoryBacking_windows.cpp

Changeset: 2f10a316
Author:    Galder Zamarre?o <galder at openjdk.org>
Committer: Roland Westrelin <roland at openjdk.org>
Date:      2024-05-15 07:48:15 +0000
URL:       https://git.openjdk.org/leyden/commit/2f10a316ff0c5a4c124b94f6fabb38fb119d2c82

8302850: Implement C1 clone intrinsic that reuses arraycopy code for primitive arrays

Reviewed-by: dlong, roland

! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.hpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.hpp
! src/hotspot/share/c1/c1_Compiler.cpp
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/c1/c1_GraphBuilder.hpp
! src/hotspot/share/c1/c1_Instruction.hpp
! src/hotspot/share/c1/c1_LIR.cpp
! src/hotspot/share/c1/c1_LIR.hpp
! src/hotspot/share/c1/c1_ValueStack.hpp
+ test/hotspot/jtreg/compiler/c1/TestNullArrayClone.java

Changeset: 957eb611
Author:    Yudi Zheng <yzheng at openjdk.org>
Committer: Doug Simon <dnsimon at openjdk.org>
Date:      2024-05-15 09:35:11 +0000
URL:       https://git.openjdk.org/leyden/commit/957eb611ce2531a3fcc764813ad1e0776887fdda

8331429: [JVMCI] Cleanup JVMCIRuntime allocation routines

Reviewed-by: dlong, dnsimon

! src/hotspot/share/gc/shared/memAllocator.hpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/jvmci/jvmciRuntime.hpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp

Changeset: 1a944478
Author:    Evgeny Astigeevich <eastigeevich at openjdk.org>
Date:      2024-05-15 09:56:05 +0000
URL:       https://git.openjdk.org/leyden/commit/1a944478a26a766f5a573a1236b642d8e7b0685c

8332111: [BACKOUT] A way to align already compiled methods with compiler directives

Reviewed-by: shade, kvn

! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/codeCache.hpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/compiler/compileTask.hpp
! src/hotspot/share/compiler/compilerDirectives.cpp
! src/hotspot/share/compiler/compilerDirectives.hpp
! src/hotspot/share/oops/method.hpp
! src/hotspot/share/oops/methodFlags.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/services/diagnosticCommand.cpp
! src/hotspot/share/services/diagnosticCommand.hpp
! test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerDirectivesDCMDTest.java
- test/hotspot/jtreg/serviceability/dcmd/compiler/DirectivesRefreshTest.java
- test/hotspot/jtreg/serviceability/dcmd/compiler/refresh_control.txt

Changeset: a5005c87
Author:    Christoph Langer <clanger at openjdk.org>
Date:      2024-05-15 10:36:24 +0000
URL:       https://git.openjdk.org/leyden/commit/a5005c87c4d5598eb54e9824105767d833f9660b

8330814: Cleanups for KeepAliveCache tests

Reviewed-by: jpai, dfuchs

! test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java
! test/jdk/sun/net/www/http/KeepAliveCache/B8291637.java
! test/jdk/sun/net/www/http/KeepAliveCache/B8293562.java
! test/jdk/sun/net/www/http/KeepAliveCache/KeepAliveProperty.java
! test/jdk/sun/net/www/http/KeepAliveCache/KeepAliveTimerThread.java

Changeset: fa043aec
Author:    Hannes Walln?fer <hannesw at openjdk.org>
Date:      2024-05-15 11:47:49 +0000
URL:       https://git.openjdk.org/leyden/commit/fa043aec425ae1e3086d09492b3fabcfbd3fa779

8294880: Review running time of jdk/internal/shellsupport/doc/JavadocHelperTest.java

Reviewed-by: jjg

! test/langtools/TEST.groups
+ test/langtools/jdk/internal/shellsupport/doc/FullJavadocHelperTest.java
! test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java

Changeset: 8032d640
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2024-05-15 12:01:20 +0000
URL:       https://git.openjdk.org/leyden/commit/8032d640c0d34fe507392a1d4faa4ff2005c771d

8332245: C2: missing record_for_ign() call in GraphKit::must_be_not_null()

Reviewed-by: thartmann, chagedorn

! src/hotspot/share/opto/graphKit.cpp
+ test/hotspot/jtreg/compiler/c2/irTests/TestBackToBackMustBeNotNull.java

Changeset: c4867c62
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-05-15 13:16:08 +0000
URL:       https://git.openjdk.org/leyden/commit/c4867c62c44b48e48845608fe4b29b58749767ad

8329273: C2 SuperWord: Some basic MemorySegment IR tests

Reviewed-by: kvn, chagedorn

+ test/hotspot/jtreg/compiler/loopopts/superword/TestMemorySegment.java

Changeset: 30bb066b
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-05-15 14:39:51 +0000
URL:       https://git.openjdk.org/leyden/commit/30bb066b1982c5318d54bfe74115306c602e2974

8332003: Clarify javadoc for MemoryLayout::offsetHandle

Reviewed-by: psandoz

! src/java.base/share/classes/java/lang/foreign/MemoryLayout.java
! test/jdk/java/foreign/TestLayoutPaths.java

Changeset: 61aff6db
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-05-15 14:57:22 +0000
URL:       https://git.openjdk.org/leyden/commit/61aff6db15d5bdda77427af5ce34d0fe43373197

8332112: Update nsk.share.Log to don't print summary during VM shutdown hook

Reviewed-by: dholmes, cjplummer

! test/hotspot/jtreg/vmTestbase/nsk/jdi/PlugConnectors/AttachConnector/plugAttachConnect001/plugAttachConnect001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/PlugConnectors/AttachConnector/plugAttachConnect002/plugAttachConnect002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/PlugConnectors/AttachConnector/plugAttachConnect003/plugAttachConnect003.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/PlugConnectors/LaunchConnector/plugLaunchConnect001/plugLaunchConnect001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/PlugConnectors/LaunchConnector/plugLaunchConnect002/plugLaunchConnect002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/PlugConnectors/LaunchConnector/plugLaunchConnect003/plugLaunchConnect003.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/PlugConnectors/ListenConnector/plugListenConnect001/plugListenConnect001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/PlugConnectors/ListenConnector/plugListenConnect002/plugListenConnect002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/PlugConnectors/ListenConnector/plugListenConnect003/plugListenConnect003.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/PlugConnectors/MultiConnectors/plugMultiConnect001/plugMultiConnect001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/PlugConnectors/MultiConnectors/plugMultiConnect002/plugMultiConnect002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/PlugConnectors/MultiConnectors/plugMultiConnect003/plugMultiConnect003.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/PlugConnectors/MultiConnectors/plugMultiConnect004/plugMultiConnect004.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/PlugConnectors/MultiConnectors/plugMultiConnect005/plugMultiConnect005.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/PlugConnectors/MultiConnectors/plugMultiConnect006/plugMultiConnect006.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/PlugConnectors/TransportService/transportService001/transportService001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/PlugConnectors/TransportService/transportService002/transportService002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/PlugConnectors/TransportService/transportService003/transportService003.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/genericSignature/genericSignature001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/genericSignature/genericSignature001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/genericSignature/genericSignature002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/genericSignature/genericSignature002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/genericSignature/genericSignature001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/genericSignature/genericSignature001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/genericSignature/genericSignature002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/genericSignature/genericSignature002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachineManager/createVirtualMachine/createVM001.java
! test/hotspot/jtreg/vmTestbase/nsk/share/Log.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java
! test/hotspot/jtreg/vmTestbase/vm/mlvm/share/MlvmTestExecutor.java

Changeset: 42ccb743
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-05-15 16:14:15 +0000
URL:       https://git.openjdk.org/leyden/commit/42ccb74399113a3d59ce016483518f033dd6e010

8331940: ClassFile API ArrayIndexOutOfBoundsException with certain class files

Reviewed-by: liach, psandoz

! src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java
! test/jdk/jdk/classfile/LimitsTest.java

Changeset: 9c02c8dd
Author:    William Kemper <wkemper at openjdk.org>
Date:      2024-05-15 16:42:19 +0000
URL:       https://git.openjdk.org/leyden/commit/9c02c8dd71023df6338cb94997bca6b00768af6f

8332255: Shenandoah: Remove duplicate definition of init mark closure

Reviewed-by: shade, kdnilsen

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp

Changeset: 491b3b45
Author:    William Kemper <wkemper at openjdk.org>
Date:      2024-05-15 16:53:04 +0000
URL:       https://git.openjdk.org/leyden/commit/491b3b45634fffb0101244f7d491a1681e7e8002

8332256: Shenandoah: Do not visit heap threads during shutdown

Reviewed-by: shade, kdnilsen

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp

Changeset: 8a4315f8
Author:    Viktor Klang <vklang at openjdk.org>
Date:      2024-05-15 18:35:46 +0000
URL:       https://git.openjdk.org/leyden/commit/8a4315f833f3700075d65fae6bc566011c837c07

8331987: Enhance stacktrace clarity for CompletableFuture CancellationException

Reviewed-by: alanb, dfuchs

! src/java.base/share/classes/java/util/concurrent/CancellationException.java
! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java
! test/jdk/java/util/concurrent/tck/CompletableFutureTest.java

Changeset: 7cff04fc
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-05-15 19:28:24 +0000
URL:       https://git.openjdk.org/leyden/commit/7cff04fc8a8114a297437aa526b18b6185831eac

8330276: Console methods with explicit Locale

Reviewed-by: joehw, rriggs, jlahoda

! src/java.base/share/classes/java/io/Console.java
! src/java.base/share/classes/java/io/ProxyingConsole.java
! src/java.base/share/classes/jdk/internal/io/JdkConsole.java
! src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/Display.java
! src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java
+ test/jdk/java/io/Console/LocaleTest.java

Changeset: 43b109b1
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2024-05-15 19:29:30 +0000
URL:       https://git.openjdk.org/leyden/commit/43b109b111e77d0f7b302debc0d76e4ac7c9ac56

8330066: HeapDumpPath and HeapDumpGzipLevel VM options do not mention HeapDumpBeforeFullGC and HeapDumpAfterFullGC

Reviewed-by: cjplummer, dholmes, yyang

! src/hotspot/share/runtime/globals.hpp

Changeset: 40832554
Author:    Rajan Halade <rhalade at openjdk.org>
Date:      2024-05-15 20:18:57 +0000
URL:       https://git.openjdk.org/leyden/commit/4083255440cfbf39b9683ea88a433d71ec6111e7

8316138: Add GlobalSign 2 TLS root certificates

Reviewed-by: mullan

+ src/java.base/share/data/cacerts/globalsigne46
+ src/java.base/share/data/cacerts/globalsignr46
! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java
! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java

Changeset: b687aa55
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2024-05-15 23:01:53 +0000
URL:       https://git.openjdk.org/leyden/commit/b687aa550837830b38f0f0faa69c353b1e85219c

8332176: Refactor ClassListParser::parse()

Reviewed-by: matsaave, ccheung

! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/cds/classListParser.hpp
! src/hotspot/share/cds/metaspaceShared.cpp

Changeset: cd261d16
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-05-15 17:59:16 +0000
URL:       https://git.openjdk.org/leyden/commit/cd261d16fbf37d411f8215f8c77ab028ce7c8daf

Merge branch 'master' of https://github.com/openjdk/leyden into premain

! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/relocInfo_aarch64.cpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/share/c1/c1_Compiler.cpp
! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/archiveBuilder.hpp
! src/hotspot/share/cds/archiveHeapWriter.cpp
! src/hotspot/share/cds/archiveUtils.cpp
! src/hotspot/share/cds/archiveUtils.hpp
! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/cds/classListParser.hpp
! src/hotspot/share/cds/cppVtables.cpp
! src/hotspot/share/cds/dynamicArchive.cpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/codeCache.hpp
! src/hotspot/share/code/relocInfo.cpp
! src/hotspot/share/code/relocInfo.hpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/compiler/compileTask.hpp
! src/hotspot/share/compiler/compilerDirectives.hpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/memory/allocation.hpp
! src/hotspot/share/oops/method.hpp
! src/hotspot/share/oops/methodFlags.hpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/vectorIntrinsics.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/thread.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FileMapInfo.java
! test/hotspot/jtreg/ProblemList.txt
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/relocInfo_aarch64.cpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/share/c1/c1_Compiler.cpp
! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/archiveBuilder.hpp
! src/hotspot/share/cds/archiveHeapWriter.cpp
! src/hotspot/share/cds/archiveUtils.cpp
! src/hotspot/share/cds/archiveUtils.hpp
! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/cds/classListParser.hpp
! src/hotspot/share/cds/cppVtables.cpp
! src/hotspot/share/cds/dynamicArchive.cpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/codeCache.hpp
! src/hotspot/share/code/relocInfo.cpp
! src/hotspot/share/code/relocInfo.hpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/compiler/compileTask.hpp
! src/hotspot/share/compiler/compilerDirectives.hpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/memory/allocation.hpp
! src/hotspot/share/oops/method.hpp
! src/hotspot/share/oops/methodFlags.hpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/vectorIntrinsics.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/thread.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FileMapInfo.java
! test/hotspot/jtreg/ProblemList.txt


From duke at openjdk.org  Fri May 17 00:19:10 2024
From: duke at openjdk.org (duke)
Date: Fri, 17 May 2024 00:19:10 GMT
Subject: git: openjdk/leyden: premain: fixed merge
Message-ID: <91dc6a8d-3660-441d-bd9f-4e77b6f93238@openjdk.org>

Changeset: d85a7e89
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-05-16 17:18:38 +0000
URL:       https://git.openjdk.org/leyden/commit/d85a7e8915c1df177ea6a2572213a2c6e000456d

fixed merge

! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/metaspaceShared.cpp


From liangchenblue at gmail.com  Fri May 17 11:23:43 2024
From: liangchenblue at gmail.com (-)
Date: Fri, 17 May 2024 06:23:43 -0500
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <a860be44e06243799593aa8d67c048cd@kth.se>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
Message-ID: <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>

Hi Aman,
For `-verbose:class`, it's a JVM argument instead of a program argument; so
when you run a java program like `java Main`, you should call it as `java
-verbose:class Main`.
When done correctly, you should see hidden class outputs like:
[0.032s][info][class,load]
java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
__JVM_LookupDefineClass__
The loading of java.lang.invoke hidden classes requires your program to use
MethodHandle features, like a lambda.

I think the problem you are exploring, that to avoid dynamic class loading
and effectively turn Java Platform closed for security, is also being
accomplished by project Leyden (as I've shared initially); Thus, I am
forwarding this to leyden-dev instead, so you can see what approach Leyden
uses to accomplish the same goal as yours.

Regards, Chen Liang

On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se> wrote:

> Hi Roger,
>
>
> Do you have ideas on how to intercept them? My javaagent is not able to
> nor a JVMTI agent passed using `agentpath` option. It also does not seem to
> show up in logs when I pass `-verbose:class`.
>
>
> Also, what do you think of renaming the proxy classes as suggested below?
>
>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Roger
> Riggs <roger.riggs at oracle.com>
> *Sent:* Friday, May 17, 2024 4:57:46 AM
> *To:* core-libs-dev at openjdk.org
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
>
> Hi Aman,
>
> You may also run into hidden classes (JEP 371: Hidden Classes) that allow
> classes to be defined, at runtime, without names.
> It has been proposed to use them for generated proxies but that hasn't
> been implemented yet.
> There are benefits to having nameless classes, because they can't be
> referenced by name, only as a capability, they can be better encapsulated.
>
> fyi, Roger Riggs
>
>
> On 5/16/24 8:11 AM, Aman Sharma wrote:
>
> Hi,
>
>
> Thanks for your response, Liang!
>
>
> > I think you meant CVE-2021-42392 instead of 2022.
>
>
> Sorry of the error. I indeed meant CVE-2021-42392
> <https://nvd.nist.gov/vuln/detail/cve-2021-42392>.
>
>
> > Leyden mainly avoids this unstable generation by performing a training
> run to collect classes loaded
>
>
> Would love to know the details of Project Leyden and how they worked so
> far to focus on this goal. In our case, the training run is the test suite.
>
>
> > GeneratedConstructorAccessor is already retired by JEP 416 [2] in Java
> 18
>
>
> I did see them not appearing in my allowlist when I ran my study subject
> (Apache PDFBox) with Java 21. Thanks for letting me know about this JEP. I
> see they are re-implemented with method handles.
>
>
> > How are you checking the classes?
>
>
> To detect runtime generated code, we have javaagent that is hooked
> statically to the test suite execution. It gives us all classes that that
> is loaded post the JVM and the javaagent are loaded. So we only check the
> classes loaded for the purpose of running the application. This is also why
> we did not choose -agentlib as it would give classes for the setting up JVM
> and javaagent and we the user of our tool must the classes they load.
>
>
> Next, we have a `ClassFileTransformer` hook in the agent where we produce
> the checksum using the bytecode. And we compare the checksum with the one
> existing in the allowlist. The checksum computation algorithm is same for
> both steps. Let me describe how I compute the checksum.
>
>
>
>    1. I get the CONSTANT_Class_info
>    <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>
>    entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info
>    <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>
>    corresponding to a fix String constant, say "foo".
>    2. Since, the name of the class is used to refer to its types members
>    (fields/method), I get all CONSTANT_Fieldref_info
>    <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>
>    and if its `class_index` corresponds to the old `this_class`, we rewrite
>    the UTF8 value of class_index to the same constant "foo".
>    3. Next, since the naming of the fields, in Proxy classes, are also
>    suffixed by numbers, for example, `private static Method m4`, we rewrite
>    the UTF8 value of name in the CONSTANT_NameAndType_info
>    <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>.
>
>    4. These fields can also have a random order so we simply sort the
>    entire byte code using `Arrays.sort(byte[])` to eliminate any differences
>    due to ordering of fields/methods.
>    5. Simply sorting the byte array still had minute differences. I could
>    not understand why they existed even though values in constant pool of the
>    bytecode in allowlist and at runtime were exactly the same after rewriting.
>    The differences existed in the bytes of the Code attribute of methods. I
>    concluded that the bytes stored some position information. To avoid this, I
>    created a subarray where I considered the bytes corresponding to `
>    CONSTANT_Utf8_info.bytes` only. Computing a checksum for it resulted
>    in the same checksums for both classfiles.
>
>
> Let's understand the whole approach with an example of Proxy class.
>
> `
>
> public final class $Proxy42 extends Proxy implements org.apache.logging.log4j.core.config.plugins.Plugin {
>
> `
>
> The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>
> When the same class is intercepted at runtime, say "$Proxy10", we look for
> "Proxy_Plugin" in the allowlist and since the checksum algorithm is same in
> both cases, we get a match and let the class load.
>
> This approach has seemed to work well for Proxy classes, Generated
> Constructor Accessor (which is removed as you said). I also looked at the
> species generated by method handles. I did not notice any modification in
> them. Their name generation seemed okay to me. If some new Species are
> generated, it is of course detected since it is not in the allowlist.
>
> I have not looked into LambdaMetafactory because I did not encounter it as
> a problem so far, but I am aware its name generation is also unstable. I
> have run my approach only a few projects only. And for hidden classes, I
> assume the the agent won't be able to intercept them so detecting them
> would be really hard.
>
>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> ------------------------------
> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
> <liangchenblue at gmail.com>
> *Sent:* Thursday, May 16, 2024 5:52:03 AM
> *To:* Aman Sharma; core-libs-dev
> *Cc:* Martin Monperrus
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
>
> Hi Aman,
> I think you meant CVE-2021-42392 instead of 2022.
>
> For your approach of an "allowlist" for Java runtime, project Leyden is
> looking to generate a static image [1], that
> > At run time it cannot load classes from outside the image, nor can it
> create classes dynamically.
> Leyden mainly avoids this unstable generation by performing a training run
> to collect classes loaded and even object graphs; I am not familiar with
> the details unfortunately.
>
> Otherwise, the Proxy discussion belongs better to core-libs-dev, as
> java.lang.reflect.Proxy is part of Java's core libraries. I am replying
> this thread to core-libs-dev.
>
> For your perceived problem that classes don't have unique names, your
> description sounds dubious: GeneratedConstructorAccessor is already retired
> by JEP 416 [2] in Java 18, and there are many other cases in which JDK
> generates classes without stable names, notoriously LambdaMetafactory
> (Gradle wished for cacheable Lambdas); the same applies for the generated
> classes for MethodHandle's LambdaForms (which carries implementation code
> for LambdaForm). How are you checking the classes? It seems you are not
> checking hidden classes. Proxy and Lambda classes are defined by the
> caller's class loader, while LambdaForms are under JDK's system class
> loader I think. We need to ensure you are correctly finding all unstable
> classes before we can proceed.
>
> [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
> [2]: https://openjdk.org/jeps/416
>
> On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se> wrote:
>
>> Hi,
>>
>>
>> My name is Aman and I am a PhD student at KTH Royal Institute of
>> Technology, Stockholm, Sweden. I research as part of CHAINS
>> <https://chains.proj.kth.se/> project to strengthen the software supply
>> chain of multiple ecosystem. I particularly focus on runtime integrity in
>> Java. In this email, I want to write about an issue I have discovered with *dynamic
>> generation of `java.lang.reflect.Proxy`classes*. I will propose a
>> solution and would love to hear the feedback from the community. Let me
>> know if this is the correct mailing-list for such discussions. It seemed
>> the most relevant from this list
>> <https://mail.openjdk.org/mailman/listinfo>.
>>
>>
>> *My research*
>>
>>
>> Java has features to load class on the fly - it can either download or
>> generate a class at runtime. These features are useful for inner workings
>> of JDK. For example, implementing annotations, reflective access, etc.
>> However, these features have also contributed to critical vulnerabilities
>> in the past - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
>> All of these vulnerabilities have one thing in common - *a class that
>> was not known during build time was downloaded/generated at runtime and
>> loaded into JVM.*
>>
>>
>> To defend against such vulnerabilities, we propose a solution to *allowlist
>> classes for runtime*. This allowlist will contain an exhaustive list of
>> classes that can be loaded by the JVM and it will be enforced at runtime.
>> We build this allowlist from three sources:
>>
>>    1. All classes of all modules provided by the Java Standard Library.
>>    We use ClassGraph <https://github.com/classgraph/classgraph> to scan
>>    the JDK.
>>    2. We can take the source code and all dependencies of an
>>    application. We use a software bill of materials to get all the data.
>>    3. Finally, we use run the test suite to include any runtime
>>    downloaded/generated classes.
>>
>> Such a list is able to prevent the above 3 CVEs because it does not let
>> the "unknown" bytecode to be loaded.
>>
>> *Problem with generating such an allowlist*
>>
>> The first two parts of the allowlist are easy to get. The problem is with
>> the third step where we want to allowlist all the classes that could be
>> downloaded or generated. Upon running the test suite and hooking to the
>> classes it loads, we observer that the list consists of classes that are
>> called "com/sun/proxy/$Proxy2", "
>> jdk/internal/reflect/GeneratedConstructorAccessor3" among many more. The
>> purpose of these classes can be identifed. The proxy class is created for
>> to implement an annotation. The accessor gives access to constructor of a
>> class to the JVM.
>>
>> When enforcing this allowlist at runtime, we see that the bytecode
>> content for "com/sun/proxy/$Proxy2" differs in the allowlist and at
>> runtime. In our case, we we are experimenting with pdfbox
>> <https://github.com/apache/pdfbox> so we created the allowlist using its
>> test suite. Then we enforced this allowlist while running some of its
>> subcommands. However, there was some other proxy class say "com/sun/proxy/$Proxy5"
>> at runtime that implemented the same interfaces and had the same methods as
>> "com/sun/proxy/$Proxy2" in the allowlist. They only differed in the name
>> of the class, order of fields, and types for fields references. This could
>> happen because the order of the loading of class is workload dependent, but
>> it causes problem to generate such an allowlist.
>>
>>
>> *Solution *
>>
>>
>> We propose that naming of subclasses of "java/lang/reflect/Proxy" should
>> not be dependent upon the order of loading. In order to do so, two issues
>> can be fixed:
>>
>>    1. The naming of the class should not be based on AtomicLong
>>    <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>.
>>    Rather it could be named based on the interfaces it implements. I also
>>    wonder why AtomicLong is chosen in the first place.
>>    2. Methods of the interfaces must be in a particular order. Right
>>    now, they are not sorted in any particular order
>>    <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>
>>    .
>>
>>
>> These fixes will make proxy class generation deterministic with respect
>> to order of loading and won't be flagged at runtime since the test suite
>> would already detect them.
>>
>> I would love to hear from the community about these ideas. If in
>> agreement, I would be happy to produce a patch. I have discovered this
>> issue with subclasses of GeneratedConstructorAccessor
>> <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>
>> as well and I imagine it will also apply to some other runtime generated
>> classes. If you disagree, please let me know also. It helps with my
>> research.
>>
>> I also have PoCs for the above CVEs
>> <https://github.com/chains-project/exploits-for-sbom.exe> and a proof
>> concept tool is being developed under the name sbom.exe
>> <https://github.com/chains-project/sbom.exe> in case any one wonders
>> about the implementation. I would also be happy to explain more.
>>
>> Regards,
>> Aman Sharma
>>
>> PhD Student
>> KTH Royal Institute of Technology
>> School of Electrical Engineering and Computer Science (EECS)
>> Department of Theoretical Computer Science (TCS)
>> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240517/a934a9ee/attachment.htm>

From david.holmes at oracle.com  Mon May 20 00:59:17 2024
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 20 May 2024 10:59:17 +1000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
Message-ID: <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>

On 17/05/2024 9:43 pm, Aman Sharma wrote:
> Hi Chen,
> 
>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
> 
> I do see this as output when I pass -verbose:class. However, based on my 
> experiments, I have seen that neither an agent passed via 'javaagent' 
> nor an agent passed via 'agentpath' is able to intercept this hidden class.

How did you try to intercept them? Hidden classes are not "loaded" in 
the normal sense so won't trigger class load events.

> Also, I was a bit confused since I saw somewhere that the names of 
> hidden classes are null. But thanks for clarifying here.

The JEP clearly defines the name format for hidden classes - though the 
final component is VM specific (and typically a hashcode).

https://openjdk.org/jeps/371

Cheers,
David
-----

>  > avoid dynamic class loading
> 
> I don't see dynamic class loading as a problem. I only mind some 
> unstable generation aspects of them which make it hard to verify them 
> based on an allowlist.
> 
> For example, if this hidden class is generated with the exact same name 
> and the exact same bytecode during runtime as well, it would be easy to 
> verify it. However, I do see the names are based on some sort of memory 
> address so and I don't know what bytecode it has so I don't have 
> suggestions to make them stable as of now. For Proxy classes, I feel it 
> can be addressed unless you disagree or some involved in Project Leyden 
> does. :) Thank you for forwarding my mail there.
> 
> Regards,
> Aman Sharma
> 
> PhD Student
> KTH Royal Institute of Technology
> https://algomaster99.github.io/ <https://algomaster99.github.io/>
> 
> ------------------------------------------------------------------------
> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
> *Sent:* Friday, May 17, 2024 1:23:58 pm
> *To:* Aman Sharma <amansha at kth.se>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>; 
> leyden-dev at openjdk.org <leyden-dev at openjdk.org>
> *Subject:* Re: Deterministic naming of subclasses of 
> `java/lang/reflect/Proxy`
> 
> Hi Aman,
> For `-verbose:class`, it's a JVM argument instead of a program argument; 
> so when you run a java program like `java Main`, you should call it as 
> `java -verbose:class Main`.
> When done correctly, you should see hidden class outputs like:
> [0.032s][info][class,load] 
> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source: 
> __JVM_LookupDefineClass__
> The?loading of java.lang.invoke hidden classes requires your program to 
> use MethodHandle features, like a lambda.
> 
> I think the problem you are exploring, that to avoid dynamic class 
> loading and effectively turn Java Platform closed for security, is also 
> being accomplished by project Leyden (as I've shared initially); Thus, I 
> am forwarding this to leyden-dev instead, so you can see what approach 
> Leyden uses to accomplish the same goal as yours.
> 
> Regards, Chen Liang
> 
> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se 
> <mailto:amansha at kth.se>> wrote:
> 
>     __
> 
>     Hi Roger,
> 
> 
>     Do you have ideas on how to intercept them? My javaagent is not able
>     to nor a JVMTI agent passed using `agentpath` option. It also does
>     not seem to show up in logs when I pass `-verbose:class`.
> 
> 
>     Also, what do you think of renaming the proxy classes as suggested
>     below?
> 
> 
>     Regards,
>     Aman Sharma
> 
>     PhD Student
>     KTH Royal Institute of Technology
>     School of Electrical Engineering and Computer Science (EECS)
>     Department of Theoretical Computer Science (TCS)
>     <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
>     <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
>     <https://algomaster99.github.io/>
>     ------------------------------------------------------------------------
>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org
>     <mailto:core-libs-dev-retn at openjdk.org>> on behalf of Roger Riggs
>     <roger.riggs at oracle.com <mailto:roger.riggs at oracle.com>>
>     *Sent:* Friday, May 17, 2024 4:57:46 AM
>     *To:* core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org>
>     *Subject:* Re: Deterministic naming of subclasses of
>     `java/lang/reflect/Proxy`
>     Hi Aman,
> 
>     You may also run into hidden classes (JEP 371: Hidden Classes) that
>     allow classes to be defined, at runtime, without names.
>     It has been proposed to use them for generated proxies but that
>     hasn't been implemented yet.
>     There are benefits to having nameless classes, because they can't be
>     referenced by name, only as a capability, they can be better
>     encapsulated.
> 
>     fyi, Roger Riggs
> 
> 
>     On 5/16/24 8:11 AM, Aman Sharma wrote:
>>
>>     Hi,
>>
>>
>>     Thanks for your response, Liang!
>>
>>
>>     > I think you meant CVE-2021-42392 instead of 2022.
>>
>>
>>     Sorry of the error. I indeed meant CVE-2021-42392
>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392>.
>>
>>
>>     > Leyden mainly avoids this unstable generation by performing a
>>     training run to collect classes loaded
>>
>>
>>     Would love to know the details of Project Leyden and how they
>>     worked so far to focus on this goal. In our case, the training run
>>     is the test suite.
>>
>>
>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>>     in Java 18
>>
>>
>>     I did see them not appearing in my allowlist when I ran my study
>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
>>     about this JEP. I see they are re-implemented with method handles.
>>
>>
>>     > How are you checking the classes?
>>
>>
>>     To detect runtime generated code, we have javaagent that is hooked
>>     statically to the test suite execution. It gives us all classes
>>     that that is loaded post the JVM and the javaagent are loaded. So
>>     we only check the classes loaded for the purpose of running the
>>     application. This is also why we did not choose -agentlib as it
>>     would give classes for the setting up JVM and javaagent and we the
>>     user of our tool must the classes they load.
>>
>>
>>     Next, we have a `ClassFileTransformer` hook in the agent where we
>>     produce the checksum using the bytecode. And we compare the
>>     checksum with the one existing in the allowlist. The checksum
>>     computation algorithm is same for both steps. Let me describe how
>>     I compute the checksum.
>>
>>
>>      1. I get the CONSTANT_Class_info
>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7> corresponding to a fix String constant, say "foo".
>>      2. Since, the name of the class is used to refer to its types
>>         members (fields/method), I get all CONSTANT_Fieldref_info
>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
>>      3. Next, since the naming of the fields, in Proxy classes, are
>>         also suffixed by numbers, for example, `private static Method
>>         m4`, we rewrite the UTF8 value of name in the
>>         CONSTANT_NameAndType_info
>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>.
>>      4. These fields can also have a random order so we simply sort
>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
>>         any differences due to ordering of fields/methods.
>>      5. Simply sorting the byte array still had minute differences. I
>>         could not understand why they existed even though values in
>>         constant pool of the bytecode in allowlist and at runtime were
>>         exactly the same after rewriting. The differences existed in
>>         the bytes of the Code attribute of methods. I concluded that
>>         the bytes stored some position information. To avoid this, I
>>         created a subarray where I considered the bytes corresponding
>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>>         it resulted in the same checksums for both classfiles. 
>>
>>
>>     Let's understand the whole approach with an example of Proxy class.
>>
>>     `
>>     public  final  class  $Proxy42  extends  Proxy  implements  org.apache.logging.log4j.core.config.plugins.Plugin  {
>>     `
>>
>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>>
>>     When the same class is intercepted at runtime, say "$Proxy10", we
>>     look for "Proxy_Plugin" in the allowlist and since the checksum
>>     algorithm is same in both cases, we get a match and let the class
>>     load.
>>
>>     This approach has seemed to work well for Proxy classes, Generated
>>     Constructor Accessor (which is removed as you said). I also looked
>>     at the species generated by method handles. I did not notice any
>>     modification in them. Their name generation seemed okay to me. If
>>     some new Species are generated, it is of course detected since it
>>     is not in the allowlist.
>>
>>     I have not looked into LambdaMetafactory because I did not
>>     encounter it as a problem so far, but I am aware its name
>>     generation is also unstable. I have run my approach only a few
>>     projects only. And for hidden classes, I assume the the agent
>>     won't be able to intercept them so detecting them would be really
>>     hard.
>>
>>
>>     Regards,
>>     Aman Sharma
>>
>>     PhD Student
>>     KTH Royal Institute of Technology
>>     School of Electrical Engineering and Computer Science (EECS)
>>     Department of Theoretical Computer Science (TCS)
>>     <https://www.kth.se/profile/amansha>https://algomaster99.github.io/ <https://algomaster99.github.io/>
>>     ------------------------------------------------------------------------
>>     *From:* liangchenblue at gmail.com <mailto:liangchenblue at gmail.com>
>>     <liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>
>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
>>     *To:* Aman Sharma; core-libs-dev
>>     *Cc:* Martin Monperrus
>>     *Subject:* Re: Deterministic naming of subclasses of
>>     `java/lang/reflect/Proxy`
>>     Hi Aman,
>>     I think you meant CVE-2021-42392 instead of 2022.
>>
>>     For your approach of an "allowlist" for Java runtime, project
>>     Leyden is looking to generate a static image [1], that
>>     >?At run time it cannot load classes from outside the image, nor
>>     can it create classes dynamically.
>>     Leyden mainly avoids this unstable generation by performing a
>>     training run to collect classes loaded and even object graphs; I
>>     am not familiar with the details unfortunately.
>>
>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
>>     replying this thread to core-libs-dev.
>>
>>     For your perceived problem that classes don't have unique names,
>>     your description sounds dubious: GeneratedConstructorAccessor is
>>     already retired by JEP 416 [2] in Java 18, and there are many
>>     other cases in which JDK generates classes without stable names,
>>     notoriously LambdaMetafactory (Gradle wished for cacheable
>>     Lambdas); the same applies for the generated classes for
>>     MethodHandle's?LambdaForms (which carries implementation code for
>>     LambdaForm). How are you checking the classes? It seems you are
>>     not checking hidden classes. Proxy and Lambda classes are defined
>>     by the caller's class loader, while LambdaForms are under JDK's
>>     system class loader I think. We need to ensure you are correctly
>>     finding all unstable classes before we can proceed.
>>
>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
>>     <https://openjdk.org/projects/leyden/notes/01-beginnings>
>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
>>
>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se
>>     <mailto:amansha at kth.se>> wrote:
>>
>>         Hi,
>>
>>
>>         My name is Aman and I am a PhD student at KTH Royal Institute
>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
>>         <https://chains.proj.kth.se/> project to strengthen the
>>         software supply chain of multiple ecosystem. I particularly
>>         focus on runtime integrity in Java. In this email, I want to
>>         write about an issue I have discovered with /dynamic
>>         generation of `java.lang.reflect.Proxy`classes/. I will
>>         propose a solution and would love to hear the feedback from
>>         the community. Let me know if this is the correct mailing-list
>>         for such discussions. It seemed the most relevant from this
>>         list <https://mail.openjdk.org/mailman/listinfo>.
>>
>>
>>         *My research*
>>
>>         *
>>         *
>>
>>         Java has features to load class on the fly - it can either
>>         download or generate a class at runtime. These features are
>>         useful for inner workings of JDK. For example, implementing
>>         annotations, reflective access, etc. However, these features
>>         have also contributed to critical vulnerabilities in the past
>>         -?CVE-2021-44228? (log4shell), CVE-2022-33980, CVE-2022-42392.
>>         All of these vulnerabilities have one thing in common - /a
>>         class that was not known during build time was
>>         downloaded/generated at runtime and loaded into JVM./
>>
>>
>>         To defend against such vulnerabilities, we propose a solution
>>         to /allowlist classes for runtime/. This allowlist will
>>         contain an exhaustive list of classes that can be loaded by
>>         the JVM and it will be enforced at runtime. We build this
>>         allowlist from three sources:
>>
>>          1. All classes of all modules provided by the Java Standard
>>             Library. We use ClassGraph
>>             <https://github.com/classgraph/classgraph> to scan the JDK.
>>          2. We can take the source code and all dependencies of an
>>             application. We use a software bill of materials to get
>>             all the data.
>>          3. Finally, we use run the test suite to include any runtime
>>             downloaded/generated classes. 
>>
>>         Such a list is able to prevent the above 3 CVEs because it
>>         does not let the "unknown" bytecode to be loaded.
>>
>>         *Problem with generating such an allowlist*
>>         *
>>         *
>>         The first two parts of the allowlist are easy to get. The
>>         problem is with the third step where we want to allowlist all
>>         the classes that could be downloaded or generated. Upon
>>         running the test suite and hooking to the classes it loads, we
>>         observer that the list consists of classes that are called
>>         "com/sun/proxy/$Proxy2",
>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>>         many more. The purpose of these classes can be identifed. The
>>         proxy class is created for to implement an annotation. The
>>         accessor gives access to constructor of a class to the JVM.
>>
>>         When enforcing this allowlist at runtime, we see that the
>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
>>         allowlist and at runtime. In our case, we we are experimenting
>>         with pdfbox <https://github.com/apache/pdfbox> so we created
>>         the allowlist using its test suite. Then we enforced this
>>         allowlist while running some of its subcommands. However,
>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
>>         at runtime that implemented the same interfaces and had the
>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>>         only differed in the name of the class, order of fields, and
>>         types for fields references. This could happen because the
>>         order of the loading of class is workload dependent, but it
>>         causes problem to generate such an allowlist.
>>
>>         *Solution
>>         *
>>
>>
>>         We propose that naming of subclasses of
>>         "java/lang/reflect/Proxy" should not be dependent upon the
>>         order of loading. In order to do so, two issues can be fixed:
>>
>>          1. The naming of the class should not be based on AtomicLong
>>             <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
>>          2. Methods of the interfaces must be in a particular order.
>>             Right now, they are not sorted in any particular order
>>             <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>.
>>
>>
>>         These fixes will make proxy class generation deterministic
>>         with respect to order of loading and won't be flagged at
>>         runtime since the test suite would already detect them.
>>
>>         I would love to hear from the community about these ideas. If
>>         in agreement, I would be happy to produce a patch. I have
>>         discovered this issue with subclasses of
>>         GeneratedConstructorAccessor
>>         <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.
>>
>>         I also have PoCs for the above CVEs
>>         <https://github.com/chains-project/exploits-for-sbom.exe> and
>>         a proof concept tool is being developed under the name
>>         sbom.exe <https://github.com/chains-project/sbom.exe> in case
>>         any one wonders about the implementation. I would also be
>>         happy to explain more.
>>
>>         Regards,
>>         Aman Sharma
>>
>>         PhD Student
>>         KTH Royal Institute of Technology
>>         School of Electrical Engineering and Computer Science (EECS)
>>         Department of Theoretical Computer Science (TCS)
>>         <https://www.kth.se/profile/amansha>https://algomaster99.github.io/ <https://algomaster99.github.io/>
>>
> 
> 

From duke at openjdk.org  Mon May 20 05:38:04 2024
From: duke at openjdk.org (duke)
Date: Mon, 20 May 2024 05:38:04 GMT
Subject: git: openjdk/leyden: premain: make/data/hotspot-symbols/symbols-unix
 is no longer needed (removed in mainline)
Message-ID: <f5c38817-63a1-482a-868e-4245b908b948@openjdk.org>

Changeset: b8b686a2
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-05-19 22:36:16 +0000
URL:       https://git.openjdk.org/leyden/commit/b8b686a2321dedc066b4c385a6bb30940e5e521a

make/data/hotspot-symbols/symbols-unix is no longer needed (removed in mainline)

- make/data/hotspot-symbols/symbols-unix


From amansha at kth.se  Mon May 20 12:12:47 2024
From: amansha at kth.se (Aman Sharma)
Date: Mon, 20 May 2024 12:12:47 +0000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>,
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
Message-ID: <b214cc1a13fe4885a437e16b420e5483@kth.se>

Hi David,


> How did you try to intercept them? Hidden classes are not "loaded" in
the normal sense so won't trigger class load events.


I could not intercept them. I only see them when I pass `-verbose:class` in the Java CLI.


I also couldn't intercept them using JVMTI Class File Load Hook<https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook> event. However JEP 371 suggests that it should be possible to intercept them using JVMTI Class Load<https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad> event, but I won't have the bytecode at this stage. So is there no way to get its bytecode before it is linked and initialized in the JVM?


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: David Holmes <david.holmes at oracle.com>
Sent: Monday, May 20, 2024 2:59:17 AM
To: Aman Sharma; liangchenblue at gmail.com
Cc: core-libs-dev at openjdk.org; leyden-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

On 17/05/2024 9:43 pm, Aman Sharma wrote:
> Hi Chen,
>
>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
>
> I do see this as output when I pass -verbose:class. However, based on my
> experiments, I have seen that neither an agent passed via 'javaagent'
> nor an agent passed via 'agentpath' is able to intercept this hidden class.

How did you try to intercept them? Hidden classes are not "loaded" in
the normal sense so won't trigger class load events.

> Also, I was a bit confused since I saw somewhere that the names of
> hidden classes are null. But thanks for clarifying here.

The JEP clearly defines the name format for hidden classes - though the
final component is VM specific (and typically a hashcode).

https://openjdk.org/jeps/371

Cheers,
David
-----

>  > avoid dynamic class loading
>
> I don't see dynamic class loading as a problem. I only mind some
> unstable generation aspects of them which make it hard to verify them
> based on an allowlist.
>
> For example, if this hidden class is generated with the exact same name
> and the exact same bytecode during runtime as well, it would be easy to
> verify it. However, I do see the names are based on some sort of memory
> address so and I don't know what bytecode it has so I don't have
> suggestions to make them stable as of now. For Proxy classes, I feel it
> can be addressed unless you disagree or some involved in Project Leyden
> does. :) Thank you for forwarding my mail there.
>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> https://algomaster99.github.io/ <https://algomaster99.github.io/>
>
> ------------------------------------------------------------------------
> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
> *Sent:* Friday, May 17, 2024 1:23:58 pm
> *To:* Aman Sharma <amansha at kth.se>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>;
> leyden-dev at openjdk.org <leyden-dev at openjdk.org>
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
>
> Hi Aman,
> For `-verbose:class`, it's a JVM argument instead of a program argument;
> so when you run a java program like `java Main`, you should call it as
> `java -verbose:class Main`.
> When done correctly, you should see hidden class outputs like:
> [0.032s][info][class,load]
> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
> __JVM_LookupDefineClass__
> The loading of java.lang.invoke hidden classes requires your program to
> use MethodHandle features, like a lambda.
>
> I think the problem you are exploring, that to avoid dynamic class
> loading and effectively turn Java Platform closed for security, is also
> being accomplished by project Leyden (as I've shared initially); Thus, I
> am forwarding this to leyden-dev instead, so you can see what approach
> Leyden uses to accomplish the same goal as yours.
>
> Regards, Chen Liang
>
> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se
> <mailto:amansha at kth.se>> wrote:
>
>     __
>
>     Hi Roger,
>
>
>     Do you have ideas on how to intercept them? My javaagent is not able
>     to nor a JVMTI agent passed using `agentpath` option. It also does
>     not seem to show up in logs when I pass `-verbose:class`.
>
>
>     Also, what do you think of renaming the proxy classes as suggested
>     below?
>
>
>     Regards,
>     Aman Sharma
>
>     PhD Student
>     KTH Royal Institute of Technology
>     School of Electrical Engineering and Computer Science (EECS)
>     Department of Theoretical Computer Science (TCS)
>     <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
>     <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
>     <https://algomaster99.github.io/>
>     ------------------------------------------------------------------------
>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org
>     <mailto:core-libs-dev-retn at openjdk.org>> on behalf of Roger Riggs
>     <roger.riggs at oracle.com <mailto:roger.riggs at oracle.com>>
>     *Sent:* Friday, May 17, 2024 4:57:46 AM
>     *To:* core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org>
>     *Subject:* Re: Deterministic naming of subclasses of
>     `java/lang/reflect/Proxy`
>     Hi Aman,
>
>     You may also run into hidden classes (JEP 371: Hidden Classes) that
>     allow classes to be defined, at runtime, without names.
>     It has been proposed to use them for generated proxies but that
>     hasn't been implemented yet.
>     There are benefits to having nameless classes, because they can't be
>     referenced by name, only as a capability, they can be better
>     encapsulated.
>
>     fyi, Roger Riggs
>
>
>     On 5/16/24 8:11 AM, Aman Sharma wrote:
>>
>>     Hi,
>>
>>
>>     Thanks for your response, Liang!
>>
>>
>>     > I think you meant CVE-2021-42392 instead of 2022.
>>
>>
>>     Sorry of the error. I indeed meant CVE-2021-42392
>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392>.
>>
>>
>>     > Leyden mainly avoids this unstable generation by performing a
>>     training run to collect classes loaded
>>
>>
>>     Would love to know the details of Project Leyden and how they
>>     worked so far to focus on this goal. In our case, the training run
>>     is the test suite.
>>
>>
>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>>     in Java 18
>>
>>
>>     I did see them not appearing in my allowlist when I ran my study
>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
>>     about this JEP. I see they are re-implemented with method handles.
>>
>>
>>     > How are you checking the classes?
>>
>>
>>     To detect runtime generated code, we have javaagent that is hooked
>>     statically to the test suite execution. It gives us all classes
>>     that that is loaded post the JVM and the javaagent are loaded. So
>>     we only check the classes loaded for the purpose of running the
>>     application. This is also why we did not choose -agentlib as it
>>     would give classes for the setting up JVM and javaagent and we the
>>     user of our tool must the classes they load.
>>
>>
>>     Next, we have a `ClassFileTransformer` hook in the agent where we
>>     produce the checksum using the bytecode. And we compare the
>>     checksum with the one existing in the allowlist. The checksum
>>     computation algorithm is same for both steps. Let me describe how
>>     I compute the checksum.
>>
>>
>>      1. I get the CONSTANT_Class_info
>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7> corresponding to a fix String constant, say "foo".
>>      2. Since, the name of the class is used to refer to its types
>>         members (fields/method), I get all CONSTANT_Fieldref_info
>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
>>      3. Next, since the naming of the fields, in Proxy classes, are
>>         also suffixed by numbers, for example, `private static Method
>>         m4`, we rewrite the UTF8 value of name in the
>>         CONSTANT_NameAndType_info
>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>.
>>      4. These fields can also have a random order so we simply sort
>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
>>         any differences due to ordering of fields/methods.
>>      5. Simply sorting the byte array still had minute differences. I
>>         could not understand why they existed even though values in
>>         constant pool of the bytecode in allowlist and at runtime were
>>         exactly the same after rewriting. The differences existed in
>>         the bytes of the Code attribute of methods. I concluded that
>>         the bytes stored some position information. To avoid this, I
>>         created a subarray where I considered the bytes corresponding
>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>>         it resulted in the same checksums for both classfiles.
>>
>>
>>     Let's understand the whole approach with an example of Proxy class.
>>
>>     `
>>     public  final  class  $Proxy42  extends  Proxy  implements  org.apache.logging.log4j.core.config.plugins.Plugin  {
>>     `
>>
>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>>
>>     When the same class is intercepted at runtime, say "$Proxy10", we
>>     look for "Proxy_Plugin" in the allowlist and since the checksum
>>     algorithm is same in both cases, we get a match and let the class
>>     load.
>>
>>     This approach has seemed to work well for Proxy classes, Generated
>>     Constructor Accessor (which is removed as you said). I also looked
>>     at the species generated by method handles. I did not notice any
>>     modification in them. Their name generation seemed okay to me. If
>>     some new Species are generated, it is of course detected since it
>>     is not in the allowlist.
>>
>>     I have not looked into LambdaMetafactory because I did not
>>     encounter it as a problem so far, but I am aware its name
>>     generation is also unstable. I have run my approach only a few
>>     projects only. And for hidden classes, I assume the the agent
>>     won't be able to intercept them so detecting them would be really
>>     hard.
>>
>>
>>     Regards,
>>     Aman Sharma
>>
>>     PhD Student
>>     KTH Royal Institute of Technology
>>     School of Electrical Engineering and Computer Science (EECS)
>>     Department of Theoretical Computer Science (TCS)
>>     <https://www.kth.se/profile/amansha>https://algomaster99.github.io/ <https://algomaster99.github.io/>
>>     ------------------------------------------------------------------------
>>     *From:* liangchenblue at gmail.com <mailto:liangchenblue at gmail.com>
>>     <liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>
>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
>>     *To:* Aman Sharma; core-libs-dev
>>     *Cc:* Martin Monperrus
>>     *Subject:* Re: Deterministic naming of subclasses of
>>     `java/lang/reflect/Proxy`
>>     Hi Aman,
>>     I think you meant CVE-2021-42392 instead of 2022.
>>
>>     For your approach of an "allowlist" for Java runtime, project
>>     Leyden is looking to generate a static image [1], that
>>     > At run time it cannot load classes from outside the image, nor
>>     can it create classes dynamically.
>>     Leyden mainly avoids this unstable generation by performing a
>>     training run to collect classes loaded and even object graphs; I
>>     am not familiar with the details unfortunately.
>>
>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
>>     replying this thread to core-libs-dev.
>>
>>     For your perceived problem that classes don't have unique names,
>>     your description sounds dubious: GeneratedConstructorAccessor is
>>     already retired by JEP 416 [2] in Java 18, and there are many
>>     other cases in which JDK generates classes without stable names,
>>     notoriously LambdaMetafactory (Gradle wished for cacheable
>>     Lambdas); the same applies for the generated classes for
>>     MethodHandle's LambdaForms (which carries implementation code for
>>     LambdaForm). How are you checking the classes? It seems you are
>>     not checking hidden classes. Proxy and Lambda classes are defined
>>     by the caller's class loader, while LambdaForms are under JDK's
>>     system class loader I think. We need to ensure you are correctly
>>     finding all unstable classes before we can proceed.
>>
>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
>>     <https://openjdk.org/projects/leyden/notes/01-beginnings>
>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
>>
>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se
>>     <mailto:amansha at kth.se>> wrote:
>>
>>         Hi,
>>
>>
>>         My name is Aman and I am a PhD student at KTH Royal Institute
>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
>>         <https://chains.proj.kth.se/> project to strengthen the
>>         software supply chain of multiple ecosystem. I particularly
>>         focus on runtime integrity in Java. In this email, I want to
>>         write about an issue I have discovered with /dynamic
>>         generation of `java.lang.reflect.Proxy`classes/. I will
>>         propose a solution and would love to hear the feedback from
>>         the community. Let me know if this is the correct mailing-list
>>         for such discussions. It seemed the most relevant from this
>>         list <https://mail.openjdk.org/mailman/listinfo>.
>>
>>
>>         *My research*
>>
>>         *
>>         *
>>
>>         Java has features to load class on the fly - it can either
>>         download or generate a class at runtime. These features are
>>         useful for inner workings of JDK. For example, implementing
>>         annotations, reflective access, etc. However, these features
>>         have also contributed to critical vulnerabilities in the past
>>         - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
>>         All of these vulnerabilities have one thing in common - /a
>>         class that was not known during build time was
>>         downloaded/generated at runtime and loaded into JVM./
>>
>>
>>         To defend against such vulnerabilities, we propose a solution
>>         to /allowlist classes for runtime/. This allowlist will
>>         contain an exhaustive list of classes that can be loaded by
>>         the JVM and it will be enforced at runtime. We build this
>>         allowlist from three sources:
>>
>>          1. All classes of all modules provided by the Java Standard
>>             Library. We use ClassGraph
>>             <https://github.com/classgraph/classgraph> to scan the JDK.
>>          2. We can take the source code and all dependencies of an
>>             application. We use a software bill of materials to get
>>             all the data.
>>          3. Finally, we use run the test suite to include any runtime
>>             downloaded/generated classes.
>>
>>         Such a list is able to prevent the above 3 CVEs because it
>>         does not let the "unknown" bytecode to be loaded.
>>
>>         *Problem with generating such an allowlist*
>>         *
>>         *
>>         The first two parts of the allowlist are easy to get. The
>>         problem is with the third step where we want to allowlist all
>>         the classes that could be downloaded or generated. Upon
>>         running the test suite and hooking to the classes it loads, we
>>         observer that the list consists of classes that are called
>>         "com/sun/proxy/$Proxy2",
>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>>         many more. The purpose of these classes can be identifed. The
>>         proxy class is created for to implement an annotation. The
>>         accessor gives access to constructor of a class to the JVM.
>>
>>         When enforcing this allowlist at runtime, we see that the
>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
>>         allowlist and at runtime. In our case, we we are experimenting
>>         with pdfbox <https://github.com/apache/pdfbox> so we created
>>         the allowlist using its test suite. Then we enforced this
>>         allowlist while running some of its subcommands. However,
>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
>>         at runtime that implemented the same interfaces and had the
>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>>         only differed in the name of the class, order of fields, and
>>         types for fields references. This could happen because the
>>         order of the loading of class is workload dependent, but it
>>         causes problem to generate such an allowlist.
>>
>>         *Solution
>>         *
>>
>>
>>         We propose that naming of subclasses of
>>         "java/lang/reflect/Proxy" should not be dependent upon the
>>         order of loading. In order to do so, two issues can be fixed:
>>
>>          1. The naming of the class should not be based on AtomicLong
>>             <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
>>          2. Methods of the interfaces must be in a particular order.
>>             Right now, they are not sorted in any particular order
>>             <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>.
>>
>>
>>         These fixes will make proxy class generation deterministic
>>         with respect to order of loading and won't be flagged at
>>         runtime since the test suite would already detect them.
>>
>>         I would love to hear from the community about these ideas. If
>>         in agreement, I would be happy to produce a patch. I have
>>         discovered this issue with subclasses of
>>         GeneratedConstructorAccessor
>>         <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.
>>
>>         I also have PoCs for the above CVEs
>>         <https://github.com/chains-project/exploits-for-sbom.exe> and
>>         a proof concept tool is being developed under the name
>>         sbom.exe <https://github.com/chains-project/sbom.exe> in case
>>         any one wonders about the implementation. I would also be
>>         happy to explain more.
>>
>>         Regards,
>>         Aman Sharma
>>
>>         PhD Student
>>         KTH Royal Institute of Technology
>>         School of Electrical Engineering and Computer Science (EECS)
>>         Department of Theoretical Computer Science (TCS)
>>         <https://www.kth.se/profile/amansha>https://algomaster99.github.io/ <https://algomaster99.github.io/>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240520/a4150a8d/attachment.htm>

From david.holmes at oracle.com  Mon May 20 12:30:37 2024
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 20 May 2024 22:30:37 +1000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <b214cc1a13fe4885a437e16b420e5483@kth.se>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>
Message-ID: <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>

On 20/05/2024 10:12 pm, Aman Sharma wrote:
> Hi David,
> 
> 
>  > How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
> 
> 
> I could not intercept them. I only see them when I pass `-verbose:class` 
> in the Java CLI.

Yes that is why I asked how you tried to intercept them.

> 
> I also couldn't intercept them using JVMTI Class File Load Hook 
> <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook> event. However JEP 371 suggests that it should be possible to intercept them using JVMTI Class Load <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad> event, but I won't have the bytecode at this stage. So is there no way to get its bytecode before it is linked and initialized in the JVM?

Hidden classes are not loaded so I would not expect any class load 
events. However the exact nature of the JVMTI class load event is 
unclear as it talks about "class or interface creation" which is neither 
loading or defining per se. But a class prepare event sounds like it 
should be issued. However neither give you access to the bytecode of the 
class AFAICS.

David
-----


> 
> Regards,
> Aman Sharma
> 
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/ 
> <https://algomaster99.github.io/>
> ------------------------------------------------------------------------
> *From:* David Holmes <david.holmes at oracle.com>
> *Sent:* Monday, May 20, 2024 2:59:17 AM
> *To:* Aman Sharma; liangchenblue at gmail.com
> *Cc:* core-libs-dev at openjdk.org; leyden-dev at openjdk.org
> *Subject:* Re: Deterministic naming of subclasses of 
> `java/lang/reflect/Proxy`
> On 17/05/2024 9:43 pm, Aman Sharma wrote:
>> Hi Chen,
>> 
>>? > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
>> 
>> I do see this as output when I pass -verbose:class. However, based on my 
>> experiments, I have seen that neither an agent passed via 'javaagent' 
>> nor an agent passed via 'agentpath' is able to intercept this hidden class.
> 
> How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
> 
>> Also, I was a bit confused since I saw somewhere that the names of 
>> hidden classes are null. But thanks for clarifying here.
> 
> The JEP clearly defines the name format for hidden classes - though the
> final component is VM specific (and typically a hashcode).
> 
> https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
> 
> Cheers,
> David
> -----
> 
>>? > avoid dynamic class loading
>> 
>> I don't see dynamic class loading as a problem. I only mind some 
>> unstable generation aspects of them which make it hard to verify them 
>> based on an allowlist.
>> 
>> For example, if this hidden class is generated with the exact same name 
>> and the exact same bytecode during runtime as well, it would be easy to 
>> verify it. However, I do see the names are based on some sort of memory 
>> address so and I don't know what bytecode it has so I don't have 
>> suggestions to make them stable as of now. For Proxy classes, I feel it 
>> can be addressed unless you disagree or some involved in Project Leyden 
>> does. :) Thank you for forwarding my mail there.
>> 
>> Regards,
>> Aman Sharma
>> 
>> PhD Student
>> KTH Royal Institute of Technology
>> https://algomaster99.github.io/ <https://algomaster99.github.io/> 
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>> 
>> ------------------------------------------------------------------------
>> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
>> *Sent:* Friday, May 17, 2024 1:23:58 pm
>> *To:* Aman Sharma <amansha at kth.se>
>> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>; 
>> leyden-dev at openjdk.org <leyden-dev at openjdk.org>
>> *Subject:* Re: Deterministic naming of subclasses of 
>> `java/lang/reflect/Proxy`
>> 
>> Hi Aman,
>> For `-verbose:class`, it's a JVM argument instead of a program argument; 
>> so when you run a java program like `java Main`, you should call it as 
>> `java -verbose:class Main`.
>> When done correctly, you should see hidden class outputs like:
>> [0.032s][info][class,load] 
>> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source: 
>> __JVM_LookupDefineClass__
>> The?loading of java.lang.invoke hidden classes requires your program to 
>> use MethodHandle features, like a lambda.
>> 
>> I think the problem you are exploring, that to avoid dynamic class 
>> loading and effectively turn Java Platform closed for security, is also 
>> being accomplished by project Leyden (as I've shared initially); Thus, I 
>> am forwarding this to leyden-dev instead, so you can see what approach 
>> Leyden uses to accomplish the same goal as yours.
>> 
>> Regards, Chen Liang
>> 
>> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se 
>> <mailto:amansha at kth.se <mailto:amansha at kth.se>>> wrote:
>> 
>>???? __
>> 
>>???? Hi Roger,
>> 
>> 
>>???? Do you have ideas on how to intercept them? My javaagent is not able
>>???? to nor a JVMTI agent passed using `agentpath` option. It also does
>>???? not seem to show up in logs when I pass `-verbose:class`.
>> 
>> 
>>???? Also, what do you think of renaming the proxy classes as suggested
>>???? below?
>> 
>> 
>>???? Regards,
>>???? Aman Sharma
>> 
>>???? PhD Student
>>???? KTH Royal Institute of Technology
>>???? School of Electrical Engineering and Computer Science (EECS)
>>???? Department of Theoretical Computer Science (TCS)
>>???? <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>>
>>???? <https://www.kth.se/profile/amansha 
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>>???? <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>???? ------------------------------------------------------------------------
>>???? *From:* core-libs-dev <core-libs-dev-retn at openjdk.org
>>???? <mailto:core-libs-dev-retn at openjdk.org 
> <mailto:core-libs-dev-retn at openjdk.org>>> on behalf of Roger Riggs
>>???? <roger.riggs at oracle.com <mailto:roger.riggs at oracle.com <mailto:roger.riggs at oracle.com>>>
>>???? *Sent:* Friday, May 17, 2024 4:57:46 AM
>>???? *To:* core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org>>
>>???? *Subject:* Re: Deterministic naming of subclasses of
>>???? `java/lang/reflect/Proxy`
>>???? Hi Aman,
>> 
>>???? You may also run into hidden classes (JEP 371: Hidden Classes) that
>>???? allow classes to be defined, at runtime, without names.
>>???? It has been proposed to use them for generated proxies but that
>>???? hasn't been implemented yet.
>>???? There are benefits to having nameless classes, because they can't be
>>???? referenced by name, only as a capability, they can be better
>>???? encapsulated.
>> 
>>???? fyi, Roger Riggs
>> 
>> 
>>???? On 5/16/24 8:11 AM, Aman Sharma wrote:
>>>
>>>???? Hi,
>>>
>>>
>>>???? Thanks for your response, Liang!
>>>
>>>
>>>???? > I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>
>>>???? Sorry of the error. I indeed meant CVE-2021-42392
>>>???? <https://nvd.nist.gov/vuln/detail/cve-2021-42392 
> <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
>>>
>>>
>>>???? > Leyden mainly avoids this unstable generation by performing a
>>>???? training run to collect classes loaded
>>>
>>>
>>>???? Would love to know the details of Project Leyden and how they
>>>???? worked so far to focus on this goal. In our case, the training run
>>>???? is the test suite.
>>>
>>>
>>>???? > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>>>???? in Java 18
>>>
>>>
>>>???? I did see them not appearing in my allowlist when I ran my study
>>>???? subject (Apache PDFBox) with Java 21. Thanks for letting me know
>>>???? about this JEP. I see they are re-implemented with method handles.
>>>
>>>
>>>???? > How are you checking the classes?
>>>
>>>
>>>???? To detect runtime generated code, we have javaagent that is hooked
>>>???? statically to the test suite execution. It gives us all classes
>>>???? that that is loaded post the JVM and the javaagent are loaded. So
>>>???? we only check the classes loaded for the purpose of running the
>>>???? application. This is also why we did not choose -agentlib as it
>>>???? would give classes for the setting up JVM and javaagent and we the
>>>???? user of our tool must the classes they load.
>>>
>>>
>>>???? Next, we have a `ClassFileTransformer` hook in the agent where we
>>>???? produce the checksum using the bytecode. And we compare the
>>>???? checksum with the one existing in the allowlist. The checksum
>>>???? computation algorithm is same for both steps. Let me describe how
>>>???? I compute the checksum.
>>>
>>>
>>>????? 1. I get the CONSTANT_Class_info
>>>???????? <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>> corresponding to a fix String constant, say "foo".
>>>????? 2. Since, the name of the class is used to refer to its types
>>>???????? members (fields/method), I get all CONSTANT_Fieldref_info
>>>???????? <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
>>>????? 3. Next, since the naming of the fields, in Proxy classes, are
>>>???????? also suffixed by numbers, for example, `private static Method
>>>???????? m4`, we rewrite the UTF8 value of name in the
>>>???????? CONSTANT_NameAndType_info
>>>???????? <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>>.
>>>????? 4. These fields can also have a random order so we simply sort
>>>???????? the entire byte code using `Arrays.sort(byte[])` to eliminate
>>>???????? any differences due to ordering of fields/methods.
>>>????? 5. Simply sorting the byte array still had minute differences. I
>>>???????? could not understand why they existed even though values in
>>>???????? constant pool of the bytecode in allowlist and at runtime were
>>>???????? exactly the same after rewriting. The differences existed in
>>>???????? the bytes of the Code attribute of methods. I concluded that
>>>???????? the bytes stored some position information. To avoid this, I
>>>???????? created a subarray where I considered the bytes corresponding
>>>???????? to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>>>???????? it resulted in the same checksums for both classfiles. 
>>>
>>>
>>>???? Let's understand the whole approach with an example of Proxy class.
>>>
>>>???? `
>>>???? public? final? class? $Proxy42? extends? Proxy? implements? org.apache.logging.log4j.core.config.plugins.Plugin? {
>>>???? `
>>>
>>>???? The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>>>
>>>???? When the same class is intercepted at runtime, say "$Proxy10", we
>>>???? look for "Proxy_Plugin" in the allowlist and since the checksum
>>>???? algorithm is same in both cases, we get a match and let the class
>>>???? load.
>>>
>>>???? This approach has seemed to work well for Proxy classes, Generated
>>>???? Constructor Accessor (which is removed as you said). I also looked
>>>???? at the species generated by method handles. I did not notice any
>>>???? modification in them. Their name generation seemed okay to me. If
>>>???? some new Species are generated, it is of course detected since it
>>>???? is not in the allowlist.
>>>
>>>???? I have not looked into LambdaMetafactory because I did not
>>>???? encounter it as a problem so far, but I am aware its name
>>>???? generation is also unstable. I have run my approach only a few
>>>???? projects only. And for hidden classes, I assume the the agent
>>>???? won't be able to intercept them so detecting them would be really
>>>???? hard.
>>>
>>>
>>>???? Regards,
>>>???? Aman Sharma
>>>
>>>???? PhD Student
>>>???? KTH Royal Institute of Technology
>>>???? School of Electrical Engineering and Computer Science (EECS)
>>>???? Department of Theoretical Computer Science (TCS)
>>>???? <https://www.kth.se/profile/amansha 
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/ 
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>???? ------------------------------------------------------------------------
>>>???? *From:* liangchenblue at gmail.com <mailto:liangchenblue at gmail.com <mailto:liangchenblue at gmail.com>>
>>>???? <liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com <mailto:liangchenblue at gmail.com>>
>>>???? *Sent:* Thursday, May 16, 2024 5:52:03 AM
>>>???? *To:* Aman Sharma; core-libs-dev
>>>???? *Cc:* Martin Monperrus
>>>???? *Subject:* Re: Deterministic naming of subclasses of
>>>???? `java/lang/reflect/Proxy`
>>>???? Hi Aman,
>>>???? I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>???? For your approach of an "allowlist" for Java runtime, project
>>>???? Leyden is looking to generate a static image [1], that
>>>???? >?At run time it cannot load classes from outside the image, nor
>>>???? can it create classes dynamically.
>>>???? Leyden mainly avoids this unstable generation by performing a
>>>???? training run to collect classes loaded and even object graphs; I
>>>???? am not familiar with the details unfortunately.
>>>
>>>???? Otherwise, the Proxy discussion belongs better to core-libs-dev,
>>>???? as java.lang.reflect.Proxy is part of Java's core libraries. I am
>>>???? replying this thread to core-libs-dev.
>>>
>>>???? For your perceived problem that classes don't have unique names,
>>>???? your description sounds dubious: GeneratedConstructorAccessor is
>>>???? already retired by JEP 416 [2] in Java 18, and there are many
>>>???? other cases in which JDK generates classes without stable names,
>>>???? notoriously LambdaMetafactory (Gradle wished for cacheable
>>>???? Lambdas); the same applies for the generated classes for
>>>???? MethodHandle's?LambdaForms (which carries implementation code for
>>>???? LambdaForm). How are you checking the classes? It seems you are
>>>???? not checking hidden classes. Proxy and Lambda classes are defined
>>>???? by the caller's class loader, while LambdaForms are under JDK's
>>>???? system class loader I think. We need to ensure you are correctly
>>>???? finding all unstable classes before we can proceed.
>>>
>>>???? [1]: https://openjdk.org/projects/leyden/notes/01-beginnings 
> <https://openjdk.org/projects/leyden/notes/01-beginnings>
>>>???? <https://openjdk.org/projects/leyden/notes/01-beginnings 
> <https://openjdk.org/projects/leyden/notes/01-beginnings>>
>>>???? [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416> 
> <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
>>>
>>>???? On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se
>>>???? <mailto:amansha at kth.se <mailto:amansha at kth.se>>> wrote:
>>>
>>>???????? Hi,
>>>
>>>
>>>???????? My name is Aman and I am a PhD student at KTH Royal Institute
>>>???????? of Technology, Stockholm, Sweden. I research as part of CHAINS
>>>???????? <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>> project to 
> strengthen the
>>>???????? software supply chain of multiple ecosystem. I particularly
>>>???????? focus on runtime integrity in Java. In this email, I want to
>>>???????? write about an issue I have discovered with /dynamic
>>>???????? generation of `java.lang.reflect.Proxy`classes/. I will
>>>???????? propose a solution and would love to hear the feedback from
>>>???????? the community. Let me know if this is the correct mailing-list
>>>???????? for such discussions. It seemed the most relevant from this
>>>???????? list <https://mail.openjdk.org/mailman/listinfo 
> <https://mail.openjdk.org/mailman/listinfo>>.
>>>
>>>
>>>???????? *My research*
>>>
>>>???????? *
>>>???????? *
>>>
>>>???????? Java has features to load class on the fly - it can either
>>>???????? download or generate a class at runtime. These features are
>>>???????? useful for inner workings of JDK. For example, implementing
>>>???????? annotations, reflective access, etc. However, these features
>>>???????? have also contributed to critical vulnerabilities in the past
>>>???????? -?CVE-2021-44228? (log4shell), CVE-2022-33980, CVE-2022-42392.
>>>???????? All of these vulnerabilities have one thing in common - /a
>>>???????? class that was not known during build time was
>>>???????? downloaded/generated at runtime and loaded into JVM./
>>>
>>>
>>>???????? To defend against such vulnerabilities, we propose a solution
>>>???????? to /allowlist classes for runtime/. This allowlist will
>>>???????? contain an exhaustive list of classes that can be loaded by
>>>???????? the JVM and it will be enforced at runtime. We build this
>>>???????? allowlist from three sources:
>>>
>>>????????? 1. All classes of all modules provided by the Java Standard
>>>???????????? Library. We use ClassGraph
>>>???????????? <https://github.com/classgraph/classgraph 
> <https://github.com/classgraph/classgraph>> to scan the JDK.
>>>????????? 2. We can take the source code and all dependencies of an
>>>???????????? application. We use a software bill of materials to get
>>>???????????? all the data.
>>>????????? 3. Finally, we use run the test suite to include any runtime
>>>???????????? downloaded/generated classes. 
>>>
>>>???????? Such a list is able to prevent the above 3 CVEs because it
>>>???????? does not let the "unknown" bytecode to be loaded.
>>>
>>>???????? *Problem with generating such an allowlist*
>>>???????? *
>>>???????? *
>>>???????? The first two parts of the allowlist are easy to get. The
>>>???????? problem is with the third step where we want to allowlist all
>>>???????? the classes that could be downloaded or generated. Upon
>>>???????? running the test suite and hooking to the classes it loads, we
>>>???????? observer that the list consists of classes that are called
>>>???????? "com/sun/proxy/$Proxy2",
>>>???????? "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>>>???????? many more. The purpose of these classes can be identifed. The
>>>???????? proxy class is created for to implement an annotation. The
>>>???????? accessor gives access to constructor of a class to the JVM.
>>>
>>>???????? When enforcing this allowlist at runtime, we see that the
>>>???????? bytecode content for "com/sun/proxy/$Proxy2" differs in the
>>>???????? allowlist and at runtime. In our case, we we are experimenting
>>>???????? with pdfbox <https://github.com/apache/pdfbox <https://github.com/apache/pdfbox>> so 
> we created
>>>???????? the allowlist using its test suite. Then we enforced this
>>>???????? allowlist while running some of its subcommands. However,
>>>???????? there was some other proxy class say "com/sun/proxy/$Proxy5"
>>>???????? at runtime that implemented the same interfaces and had the
>>>???????? same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>>>???????? only differed in the name of the class, order of fields, and
>>>???????? types for fields references. This could happen because the
>>>???????? order of the loading of class is workload dependent, but it
>>>???????? causes problem to generate such an allowlist.
>>>
>>>???????? *Solution
>>>???????? *
>>>
>>>
>>>???????? We propose that naming of subclasses of
>>>???????? "java/lang/reflect/Proxy" should not be dependent upon the
>>>???????? order of loading. In order to do so, two issues can be fixed:
>>>
>>>????????? 1. The naming of the class should not be based on AtomicLong
>>>???????????? <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531 <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
>>>????????? 2. Methods of the interfaces must be in a particular order.
>>>???????????? Right now, they are not sorted in any particular order
>>>???????????? <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178 <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>>.
>>>
>>>
>>>???????? These fixes will make proxy class generation deterministic
>>>???????? with respect to order of loading and won't be flagged at
>>>???????? runtime since the test suite would already detect them.
>>>
>>>???????? I would love to hear from the community about these ideas. If
>>>???????? in agreement, I would be happy to produce a patch. I have
>>>???????? discovered this issue with subclasses of
>>>???????? GeneratedConstructorAccessor
>>>???????? <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.
>>>
>>>???????? I also have PoCs for the above CVEs
>>>???????? <https://github.com/chains-project/exploits-for-sbom.exe 
> <https://github.com/chains-project/exploits-for-sbom.exe>> and
>>>???????? a proof concept tool is being developed under the name
>>>???????? sbom.exe <https://github.com/chains-project/sbom.exe 
> <https://github.com/chains-project/sbom.exe>> in case
>>>???????? any one wonders about the implementation. I would also be
>>>???????? happy to explain more.
>>>
>>>???????? Regards,
>>>???????? Aman Sharma
>>>
>>>???????? PhD Student
>>>???????? KTH Royal Institute of Technology
>>>???????? School of Electrical Engineering and Computer Science (EECS)
>>>???????? Department of Theoretical Computer Science (TCS)
>>>???????? <https://www.kth.se/profile/amansha 
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/ 
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>
>> 
>> 

From amansha at kth.se  Mon May 20 12:56:30 2024
From: amansha at kth.se (Aman Sharma)
Date: Mon, 20 May 2024 12:56:30 +0000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>,
 <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
Message-ID: <580b3aacd8df48fcaae3399718e229ab@kth.se>

Hi David,


> I would not expect any class load
events.


I understand. I also haven't tried to intercept them but I see only one approach right now to include them in an allowlist - 1) statically look for invocations of "Lookup::defineHiddenClass". 2) Instrument them so that its first argument "bytes" can be looked into upon. I haven't looked into it much because I did not have much idea about it. And they are hidden so it made it worse. ? Thanks for sharing the JEP!


>

java.lang.reflect.Proxy could define hidden classes to act as the proxy classes which implement proxy interfaces; from JEP 317


It says that Proxy classes will also become hidden classes. Is it underway? Right now one can intercept, transform them, and include them in an allowlist. What do you think of naming them independent of AtomicLong so that a proxy class generated at runtime is easy to lookup in the allowlist?



Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: David Holmes <david.holmes at oracle.com>
Sent: Monday, May 20, 2024 2:30:37 PM
To: Aman Sharma; liangchenblue at gmail.com
Cc: core-libs-dev at openjdk.org; leyden-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

On 20/05/2024 10:12 pm, Aman Sharma wrote:
> Hi David,
>
>
>  > How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>
> I could not intercept them. I only see them when I pass `-verbose:class`
> in the Java CLI.

Yes that is why I asked how you tried to intercept them.

>
> I also couldn't intercept them using JVMTI Class File Load Hook
> <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook> event. However JEP 371 suggests that it should be possible to intercept them using JVMTI Class Load <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad> event, but I won't have the bytecode at this stage. So is there no way to get its bytecode before it is linked and initialized in the JVM?

Hidden classes are not loaded so I would not expect any class load
events. However the exact nature of the JVMTI class load event is
unclear as it talks about "class or interface creation" which is neither
loading or defining per se. But a class prepare event sounds like it
should be issued. However neither give you access to the bytecode of the
class AFAICS.

David
-----


>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> <https://algomaster99.github.io/>
> ------------------------------------------------------------------------
> *From:* David Holmes <david.holmes at oracle.com>
> *Sent:* Monday, May 20, 2024 2:59:17 AM
> *To:* Aman Sharma; liangchenblue at gmail.com
> *Cc:* core-libs-dev at openjdk.org; leyden-dev at openjdk.org
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
> On 17/05/2024 9:43 pm, Aman Sharma wrote:
>> Hi Chen,
>>
>>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
>>
>> I do see this as output when I pass -verbose:class. However, based on my
>> experiments, I have seen that neither an agent passed via 'javaagent'
>> nor an agent passed via 'agentpath' is able to intercept this hidden class.
>
> How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>> Also, I was a bit confused since I saw somewhere that the names of
>> hidden classes are null. But thanks for clarifying here.
>
> The JEP clearly defines the name format for hidden classes - though the
> final component is VM specific (and typically a hashcode).
>
> https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
>
> Cheers,
> David
> -----
>
>>  > avoid dynamic class loading
>>
>> I don't see dynamic class loading as a problem. I only mind some
>> unstable generation aspects of them which make it hard to verify them
>> based on an allowlist.
>>
>> For example, if this hidden class is generated with the exact same name
>> and the exact same bytecode during runtime as well, it would be easy to
>> verify it. However, I do see the names are based on some sort of memory
>> address so and I don't know what bytecode it has so I don't have
>> suggestions to make them stable as of now. For Proxy classes, I feel it
>> can be addressed unless you disagree or some involved in Project Leyden
>> does. :) Thank you for forwarding my mail there.
>>
>> Regards,
>> Aman Sharma
>>
>> PhD Student
>> KTH Royal Institute of Technology
>> https://algomaster99.github.io/ <https://algomaster99.github.io/>
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>
>> ------------------------------------------------------------------------
>> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
>> *Sent:* Friday, May 17, 2024 1:23:58 pm
>> *To:* Aman Sharma <amansha at kth.se>
>> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>;
>> leyden-dev at openjdk.org <leyden-dev at openjdk.org>
>> *Subject:* Re: Deterministic naming of subclasses of
>> `java/lang/reflect/Proxy`
>>
>> Hi Aman,
>> For `-verbose:class`, it's a JVM argument instead of a program argument;
>> so when you run a java program like `java Main`, you should call it as
>> `java -verbose:class Main`.
>> When done correctly, you should see hidden class outputs like:
>> [0.032s][info][class,load]
>> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
>> __JVM_LookupDefineClass__
>> The loading of java.lang.invoke hidden classes requires your program to
>> use MethodHandle features, like a lambda.
>>
>> I think the problem you are exploring, that to avoid dynamic class
>> loading and effectively turn Java Platform closed for security, is also
>> being accomplished by project Leyden (as I've shared initially); Thus, I
>> am forwarding this to leyden-dev instead, so you can see what approach
>> Leyden uses to accomplish the same goal as yours.
>>
>> Regards, Chen Liang
>>
>> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se
>> <mailto:amansha at kth.se <mailto:amansha at kth.se>>> wrote:
>>
>>     __
>>
>>     Hi Roger,
>>
>>
>>     Do you have ideas on how to intercept them? My javaagent is not able
>>     to nor a JVMTI agent passed using `agentpath` option. It also does
>>     not seem to show up in logs when I pass `-verbose:class`.
>>
>>
>>     Also, what do you think of renaming the proxy classes as suggested
>>     below?
>>
>>
>>     Regards,
>>     Aman Sharma
>>
>>     PhD Student
>>     KTH Royal Institute of Technology
>>     School of Electrical Engineering and Computer Science (EECS)
>>     Department of Theoretical Computer Science (TCS)
>>     <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>>
>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>>     <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>     ------------------------------------------------------------------------
>>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org
>>     <mailto:core-libs-dev-retn at openjdk.org
> <mailto:core-libs-dev-retn at openjdk.org>>> on behalf of Roger Riggs
>>     <roger.riggs at oracle.com <mailto:roger.riggs at oracle.com <mailto:roger.riggs at oracle.com>>>
>>     *Sent:* Friday, May 17, 2024 4:57:46 AM
>>     *To:* core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org>>
>>     *Subject:* Re: Deterministic naming of subclasses of
>>     `java/lang/reflect/Proxy`
>>     Hi Aman,
>>
>>     You may also run into hidden classes (JEP 371: Hidden Classes) that
>>     allow classes to be defined, at runtime, without names.
>>     It has been proposed to use them for generated proxies but that
>>     hasn't been implemented yet.
>>     There are benefits to having nameless classes, because they can't be
>>     referenced by name, only as a capability, they can be better
>>     encapsulated.
>>
>>     fyi, Roger Riggs
>>
>>
>>     On 5/16/24 8:11 AM, Aman Sharma wrote:
>>>
>>>     Hi,
>>>
>>>
>>>     Thanks for your response, Liang!
>>>
>>>
>>>     > I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>
>>>     Sorry of the error. I indeed meant CVE-2021-42392
>>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392
> <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
>>>
>>>
>>>     > Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded
>>>
>>>
>>>     Would love to know the details of Project Leyden and how they
>>>     worked so far to focus on this goal. In our case, the training run
>>>     is the test suite.
>>>
>>>
>>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>>>     in Java 18
>>>
>>>
>>>     I did see them not appearing in my allowlist when I ran my study
>>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
>>>     about this JEP. I see they are re-implemented with method handles.
>>>
>>>
>>>     > How are you checking the classes?
>>>
>>>
>>>     To detect runtime generated code, we have javaagent that is hooked
>>>     statically to the test suite execution. It gives us all classes
>>>     that that is loaded post the JVM and the javaagent are loaded. So
>>>     we only check the classes loaded for the purpose of running the
>>>     application. This is also why we did not choose -agentlib as it
>>>     would give classes for the setting up JVM and javaagent and we the
>>>     user of our tool must the classes they load.
>>>
>>>
>>>     Next, we have a `ClassFileTransformer` hook in the agent where we
>>>     produce the checksum using the bytecode. And we compare the
>>>     checksum with the one existing in the allowlist. The checksum
>>>     computation algorithm is same for both steps. Let me describe how
>>>     I compute the checksum.
>>>
>>>
>>>      1. I get the CONSTANT_Class_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>> corresponding to a fix String constant, say "foo".
>>>      2. Since, the name of the class is used to refer to its types
>>>         members (fields/method), I get all CONSTANT_Fieldref_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
>>>      3. Next, since the naming of the fields, in Proxy classes, are
>>>         also suffixed by numbers, for example, `private static Method
>>>         m4`, we rewrite the UTF8 value of name in the
>>>         CONSTANT_NameAndType_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>>.
>>>      4. These fields can also have a random order so we simply sort
>>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
>>>         any differences due to ordering of fields/methods.
>>>      5. Simply sorting the byte array still had minute differences. I
>>>         could not understand why they existed even though values in
>>>         constant pool of the bytecode in allowlist and at runtime were
>>>         exactly the same after rewriting. The differences existed in
>>>         the bytes of the Code attribute of methods. I concluded that
>>>         the bytes stored some position information. To avoid this, I
>>>         created a subarray where I considered the bytes corresponding
>>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>>>         it resulted in the same checksums for both classfiles.
>>>
>>>
>>>     Let's understand the whole approach with an example of Proxy class.
>>>
>>>     `
>>>     public  final  class  $Proxy42  extends  Proxy  implements  org.apache.logging.log4j.core.config.plugins.Plugin  {
>>>     `
>>>
>>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>>>
>>>     When the same class is intercepted at runtime, say "$Proxy10", we
>>>     look for "Proxy_Plugin" in the allowlist and since the checksum
>>>     algorithm is same in both cases, we get a match and let the class
>>>     load.
>>>
>>>     This approach has seemed to work well for Proxy classes, Generated
>>>     Constructor Accessor (which is removed as you said). I also looked
>>>     at the species generated by method handles. I did not notice any
>>>     modification in them. Their name generation seemed okay to me. If
>>>     some new Species are generated, it is of course detected since it
>>>     is not in the allowlist.
>>>
>>>     I have not looked into LambdaMetafactory because I did not
>>>     encounter it as a problem so far, but I am aware its name
>>>     generation is also unstable. I have run my approach only a few
>>>     projects only. And for hidden classes, I assume the the agent
>>>     won't be able to intercept them so detecting them would be really
>>>     hard.
>>>
>>>
>>>     Regards,
>>>     Aman Sharma
>>>
>>>     PhD Student
>>>     KTH Royal Institute of Technology
>>>     School of Electrical Engineering and Computer Science (EECS)
>>>     Department of Theoretical Computer Science (TCS)
>>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>     ------------------------------------------------------------------------
>>>     *From:* liangchenblue at gmail.com <mailto:liangchenblue at gmail.com <mailto:liangchenblue at gmail.com>>
>>>     <liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com <mailto:liangchenblue at gmail.com>>
>>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
>>>     *To:* Aman Sharma; core-libs-dev
>>>     *Cc:* Martin Monperrus
>>>     *Subject:* Re: Deterministic naming of subclasses of
>>>     `java/lang/reflect/Proxy`
>>>     Hi Aman,
>>>     I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>     For your approach of an "allowlist" for Java runtime, project
>>>     Leyden is looking to generate a static image [1], that
>>>     > At run time it cannot load classes from outside the image, nor
>>>     can it create classes dynamically.
>>>     Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded and even object graphs; I
>>>     am not familiar with the details unfortunately.
>>>
>>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
>>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
>>>     replying this thread to core-libs-dev.
>>>
>>>     For your perceived problem that classes don't have unique names,
>>>     your description sounds dubious: GeneratedConstructorAccessor is
>>>     already retired by JEP 416 [2] in Java 18, and there are many
>>>     other cases in which JDK generates classes without stable names,
>>>     notoriously LambdaMetafactory (Gradle wished for cacheable
>>>     Lambdas); the same applies for the generated classes for
>>>     MethodHandle's LambdaForms (which carries implementation code for
>>>     LambdaForm). How are you checking the classes? It seems you are
>>>     not checking hidden classes. Proxy and Lambda classes are defined
>>>     by the caller's class loader, while LambdaForms are under JDK's
>>>     system class loader I think. We need to ensure you are correctly
>>>     finding all unstable classes before we can proceed.
>>>
>>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>
>>>     <https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>>
>>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
> <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
>>>
>>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se
>>>     <mailto:amansha at kth.se <mailto:amansha at kth.se>>> wrote:
>>>
>>>         Hi,
>>>
>>>
>>>         My name is Aman and I am a PhD student at KTH Royal Institute
>>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
>>>         <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>> project to
> strengthen the
>>>         software supply chain of multiple ecosystem. I particularly
>>>         focus on runtime integrity in Java. In this email, I want to
>>>         write about an issue I have discovered with /dynamic
>>>         generation of `java.lang.reflect.Proxy`classes/. I will
>>>         propose a solution and would love to hear the feedback from
>>>         the community. Let me know if this is the correct mailing-list
>>>         for such discussions. It seemed the most relevant from this
>>>         list <https://mail.openjdk.org/mailman/listinfo
> <https://mail.openjdk.org/mailman/listinfo>>.
>>>
>>>
>>>         *My research*
>>>
>>>         *
>>>         *
>>>
>>>         Java has features to load class on the fly - it can either
>>>         download or generate a class at runtime. These features are
>>>         useful for inner workings of JDK. For example, implementing
>>>         annotations, reflective access, etc. However, these features
>>>         have also contributed to critical vulnerabilities in the past
>>>         - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
>>>         All of these vulnerabilities have one thing in common - /a
>>>         class that was not known during build time was
>>>         downloaded/generated at runtime and loaded into JVM./
>>>
>>>
>>>         To defend against such vulnerabilities, we propose a solution
>>>         to /allowlist classes for runtime/. This allowlist will
>>>         contain an exhaustive list of classes that can be loaded by
>>>         the JVM and it will be enforced at runtime. We build this
>>>         allowlist from three sources:
>>>
>>>          1. All classes of all modules provided by the Java Standard
>>>             Library. We use ClassGraph
>>>             <https://github.com/classgraph/classgraph
> <https://github.com/classgraph/classgraph>> to scan the JDK.
>>>          2. We can take the source code and all dependencies of an
>>>             application. We use a software bill of materials to get
>>>             all the data.
>>>          3. Finally, we use run the test suite to include any runtime
>>>             downloaded/generated classes.
>>>
>>>         Such a list is able to prevent the above 3 CVEs because it
>>>         does not let the "unknown" bytecode to be loaded.
>>>
>>>         *Problem with generating such an allowlist*
>>>         *
>>>         *
>>>         The first two parts of the allowlist are easy to get. The
>>>         problem is with the third step where we want to allowlist all
>>>         the classes that could be downloaded or generated. Upon
>>>         running the test suite and hooking to the classes it loads, we
>>>         observer that the list consists of classes that are called
>>>         "com/sun/proxy/$Proxy2",
>>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>>>         many more. The purpose of these classes can be identifed. The
>>>         proxy class is created for to implement an annotation. The
>>>         accessor gives access to constructor of a class to the JVM.
>>>
>>>         When enforcing this allowlist at runtime, we see that the
>>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
>>>         allowlist and at runtime. In our case, we we are experimenting
>>>         with pdfbox <https://github.com/apache/pdfbox <https://github.com/apache/pdfbox>> so
> we created
>>>         the allowlist using its test suite. Then we enforced this
>>>         allowlist while running some of its subcommands. However,
>>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
>>>         at runtime that implemented the same interfaces and had the
>>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>>>         only differed in the name of the class, order of fields, and
>>>         types for fields references. This could happen because the
>>>         order of the loading of class is workload dependent, but it
>>>         causes problem to generate such an allowlist.
>>>
>>>         *Solution
>>>         *
>>>
>>>
>>>         We propose that naming of subclasses of
>>>         "java/lang/reflect/Proxy" should not be dependent upon the
>>>         order of loading. In order to do so, two issues can be fixed:
>>>
>>>          1. The naming of the class should not be based on AtomicLong
>>>             <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531 <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
>>>          2. Methods of the interfaces must be in a particular order.
>>>             Right now, they are not sorted in any particular order
>>>             <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178 <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>>.
>>>
>>>
>>>         These fixes will make proxy class generation deterministic
>>>         with respect to order of loading and won't be flagged at
>>>         runtime since the test suite would already detect them.
>>>
>>>         I would love to hear from the community about these ideas. If
>>>         in agreement, I would be happy to produce a patch. I have
>>>         discovered this issue with subclasses of
>>>         GeneratedConstructorAccessor
>>>         <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.
>>>
>>>         I also have PoCs for the above CVEs
>>>         <https://github.com/chains-project/exploits-for-sbom.exe
> <https://github.com/chains-project/exploits-for-sbom.exe>> and
>>>         a proof concept tool is being developed under the name
>>>         sbom.exe <https://github.com/chains-project/sbom.exe
> <https://github.com/chains-project/sbom.exe>> in case
>>>         any one wonders about the implementation. I would also be
>>>         happy to explain more.
>>>
>>>         Regards,
>>>         Aman Sharma
>>>
>>>         PhD Student
>>>         KTH Royal Institute of Technology
>>>         School of Electrical Engineering and Computer Science (EECS)
>>>         Department of Theoretical Computer Science (TCS)
>>>         <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240520/9d46e891/attachment.htm>

From jianglizhou at google.com  Tue May 21 05:17:45 2024
From: jianglizhou at google.com (Jiangli Zhou)
Date: Mon, 20 May 2024 22:17:45 -0700
Subject: Hermetic Java project meeting
In-Reply-To: <6090f2aa-1480-4706-9281-035579a933af@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>
 <CALrW1jwiQ=HOknmPehQQxc5W3mBSNfX+dzeGBaf73=g-h7hDgg@mail.gmail.com>
 <779749fa-8427-4b48-b897-5210b36d5be8@oracle.com>
 <CALrW1jzzQ8pkkXDmvM-9WbbdSiTrARZgnm6-x2V4zKC053RzgA@mail.gmail.com>
 <6090f2aa-1480-4706-9281-035579a933af@oracle.com>
Message-ID: <CALrW1jyeJctmpV6WM+jQX8gqh0=AmfbfuD8iThH0pie5uF=hAg@mail.gmail.com>

On Tue, May 7, 2024 at 5:26?AM Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> On 2024-05-07 06:04, Jiangli Zhou wrote:
>
> On Tue, Apr 30, 2024 at 5:42?AM Magnus Ihse Bursie<magnus.ihse.bursie at oracle.com> <magnus.ihse.bursie at oracle.com> wrote:
>
> 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 decided to spend the time to reinstall my machine. Now linking with
> clang works. Kind of. For some reason, it still picks up binutils ld and
> not lld, and then -l:libc++.a does not work, but when I replaced it with
> -l:libstdc++.a it worked just fine. I guess we need to either forcefully
> add -fuse-ld=lld to our clang compilation lines, or figure out if clang is
> going to call the binutils or llvm ld, and select the right option.
>

https://lld.llvm.org/#using-lld has some information on using lld instead
of the default linker.


> I still find the logic for how clang and gcc locates the default linker to
> be mostly magic. I guess I need to make a deep dive in understanding this
> to be able to resolve this properly.
>
> The JDK and VM code has pre-existing assumptions about the JDK
> directories and dynamic linking (e.g. the .so).
> JLI_IsStaticJDK|JLI_SetStaticJDK|JVM_IsStaticJDK|JVM_SetStaticJDK is
> needed for static JDK support to handle those cases correctly.
> CreateExecutionEnvironment that I mentioned earlier is one of the
> examples.
>
> I'm quite certain the issue that you are running into is due to the
> incorrect static check/handling in CreateExecutionEnvironment.
>
> I'll have a look at that, thanks for the pointer.
>
> 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 haven't seen your branch/code. I'd suggest not going with the #ifdef
> checks as that's the opposite direction of what we want to achieve. It
> doesn't seem to be worth your effort to add more #ifdef checks in
> order to do static linking build work, even those are for temporary
> testing reasons.
>
> Okaaaaay... My understanding was that you wanted to push for the quickest
> possible integration of building a static java launcher into mainline.
>
That's correct. Please see more details below.

> To do that as fast as possible, we need to use the existing framework for
> separating statically and dynamically linked libraries, which means doing
> compile time checks using #ifdefs.
>
Using #ifdefs is not the most efficient path for us to get static Java
launcher support in mainline. That's because most of the runtime changes
for static Java support in hermetic-java-runtime branch are already done
using `JLI_IsStaticJDK|JVM_IsStaticJDK` checks. We should not convert those
to use #ifdefs then later convert the #ifdef back to runtime checks again
during the integration work.

As suggested and discussed earlier we can aim to get the static Java
related changes into mainline incrementally. Following is a path that I
think would work effectively and "fast" by limiting potentially wasted
efforts:

Step 1 - Get the makefile changes for linking `javastatic` without any of
the runtime changes; Don't enable any build and testing for `javastatic` in
this step yet
Step 2 - Incrementally get the runtime changes reviewed and integrated into
mainline;
              Enable building for `javastatic` as a test in github workflow
when we can run HelloWorld using static launcher in mainline;
              Enable testing tier 1 for `javastatic` in workflow when we
can run jtreg tests with the static launcher - could be done in a later
step;
Step 3 - Remove all STATIC_BUILD macros in JDK runtime code; Also cleanup
the macros in tests (can be done later)
              CSR and JNI specification work to support
JNI_OnLoad_<lib_name> and friends for JNI dynamic library and builtin
library
Step 4 - Build (makefile) changes to support linking .a and .so libraries
using the same set of .o objects, to avoid compiling the .c/.c++ source
twice

Those lay the foundation for the hermetic Java work in mainline.

> Are you saying now that the priorities has changed, and that you want to
> start by introducing your framework for the runtime lookup if we are static
> or dynamic?
>
By "runtime lookup", I think you were referring to the JNI native library
lookup. We can handle them as part of the step 2 above.

I think for any of the runtime changes, we need to be able to build in the
mainline (although initially not included in the github workflow).

>
> To be honest, I think your prototype is rather hacky in how you implement
> this, and I reckon that it will require quite a lot of work to be accepted
> into mainline. I also think you need a CSR for changing the Hotspot/JDK
> behavior wrt this, which further adds to the process.
>

For CSR work, we can do that as part of step #3. Actually, for the
builtin/dynamic library lookup support, I think the enhancements in
hermetic-java-runtime are already close to the proper shape (not hacky).


> If you want to go that route instead, then I'll put my work on hold until
> you have gotten a working solution for the runtime lookup in mainline. I
> gather this means that there is no real stress for me anymore.
>
Ron and Alan mentioned Tuesday morning PT may not work the best for you.
Would you be open for a separate time to discuss the details on moving
forward?

Best,
Jiangli


>
> /Magnus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240520/4deb22e0/attachment.htm>

From jianglizhou at google.com  Tue May 21 18:51:51 2024
From: jianglizhou at google.com (Jiangli Zhou)
Date: Tue, 21 May 2024 11:51:51 -0700
Subject: Hermetic Java project meeting
In-Reply-To: <CALrW1jyeJctmpV6WM+jQX8gqh0=AmfbfuD8iThH0pie5uF=hAg@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>
 <779749fa-8427-4b48-b897-5210b36d5be8@oracle.com>
 <CALrW1jzzQ8pkkXDmvM-9WbbdSiTrARZgnm6-x2V4zKC053RzgA@mail.gmail.com>
 <6090f2aa-1480-4706-9281-035579a933af@oracle.com>
 <CALrW1jyeJctmpV6WM+jQX8gqh0=AmfbfuD8iThH0pie5uF=hAg@mail.gmail.com>
Message-ID: <CALrW1jw=NNkk9Tars4UZh3keCvcpRgWQeqprxJQz=vGUMZDvOQ@mail.gmail.com>

We had a discussion on static Java this morning. Outcome of today's
discussion:

For the first step in earlier outlined steps, there's a preference to have
a minimum buildable and runnable (be able to run HelloWorld) `javastatic`
as the initial integration point for the mainline. Following are the
updated plan/steps:

Step 1 - Get the makefile changes for linking `javastatic` with minimum
needed runtime changes into mainline;
              `javastatic` is buildable and runnable - can run HelloWorld
              Can enable build and testing for `javastatic` in github
workflow
Step 2 - Incrementally get the runtime changes reviewed and integrated into
mainline;
              Revert any of the #ifdef changes if they were introduced in
the first step
              Enable testing tier 1 for `javastatic` in workflow when we
can run jtreg tests with the static launcher - could be done in a later
step;
Step 3 - Remove all STATIC_BUILD macros in JDK runtime code; Also cleanup
the macros in tests (can be done later)
              CSR and JNI specification work to support
JNI_OnLoad_<lib_name> and friends for JNI dynamic library and builtin
library
Step 4 - Build (makefile) changes to support linking .a and .so libraries
using the same set of .o objects, to avoid compiling the .c/.c++ source
twice

According to Magnus, his #ifdef changes only affect about half a dozen
files. Those #ifdef are inserted in places where the
JLI_IsStaticJDK|JVM_IsStaticJDK checks are used in the
hermetic-java-runtime branch. Magnus will send out his changes as PR draft
for initial review for deciding on how to move forward with the
non-makefile changes. If the #ifdef changes are not too disruptive, we
could include those in the initial integration work. Then the followup
runtime changes would revert the #ifdef changes.

Best,
Jiangli

On Mon, May 20, 2024 at 10:17?PM Jiangli Zhou <jianglizhou at google.com>
wrote:

> On Tue, May 7, 2024 at 5:26?AM Magnus Ihse Bursie <
> magnus.ihse.bursie at oracle.com> wrote:
>
>> On 2024-05-07 06:04, Jiangli Zhou wrote:
>>
>> On Tue, Apr 30, 2024 at 5:42?AM Magnus Ihse Bursie<magnus.ihse.bursie at oracle.com> <magnus.ihse.bursie at oracle.com> wrote:
>>
>> 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 decided to spend the time to reinstall my machine. Now linking with
>> clang works. Kind of. For some reason, it still picks up binutils ld and
>> not lld, and then -l:libc++.a does not work, but when I replaced it with
>> -l:libstdc++.a it worked just fine. I guess we need to either forcefully
>> add -fuse-ld=lld to our clang compilation lines, or figure out if clang is
>> going to call the binutils or llvm ld, and select the right option.
>>
>
> https://lld.llvm.org/#using-lld has some information on using lld instead
> of the default linker.
>
>
>> I still find the logic for how clang and gcc locates the default linker
>> to be mostly magic. I guess I need to make a deep dive in understanding
>> this to be able to resolve this properly.
>>
>> The JDK and VM code has pre-existing assumptions about the JDK
>> directories and dynamic linking (e.g. the .so).
>> JLI_IsStaticJDK|JLI_SetStaticJDK|JVM_IsStaticJDK|JVM_SetStaticJDK is
>> needed for static JDK support to handle those cases correctly.
>> CreateExecutionEnvironment that I mentioned earlier is one of the
>> examples.
>>
>> I'm quite certain the issue that you are running into is due to the
>> incorrect static check/handling in CreateExecutionEnvironment.
>>
>> I'll have a look at that, thanks for the pointer.
>>
>> 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 haven't seen your branch/code. I'd suggest not going with the #ifdef
>> checks as that's the opposite direction of what we want to achieve. It
>> doesn't seem to be worth your effort to add more #ifdef checks in
>> order to do static linking build work, even those are for temporary
>> testing reasons.
>>
>> Okaaaaay... My understanding was that you wanted to push for the quickest
>> possible integration of building a static java launcher into mainline.
>>
> That's correct. Please see more details below.
>
>> To do that as fast as possible, we need to use the existing framework for
>> separating statically and dynamically linked libraries, which means doing
>> compile time checks using #ifdefs.
>>
> Using #ifdefs is not the most efficient path for us to get static Java
> launcher support in mainline. That's because most of the runtime changes
> for static Java support in hermetic-java-runtime branch are already done
> using `JLI_IsStaticJDK|JVM_IsStaticJDK` checks. We should not convert those
> to use #ifdefs then later convert the #ifdef back to runtime checks again
> during the integration work.
>
> As suggested and discussed earlier we can aim to get the static Java
> related changes into mainline incrementally. Following is a path that I
> think would work effectively and "fast" by limiting potentially wasted
> efforts:
>
> Step 1 - Get the makefile changes for linking `javastatic` without any of
> the runtime changes; Don't enable any build and testing for `javastatic` in
> this step yet
> Step 2 - Incrementally get the runtime changes reviewed and integrated
> into mainline;
>               Enable building for `javastatic` as a test in github
> workflow when we can run HelloWorld using static launcher in mainline;
>               Enable testing tier 1 for `javastatic` in workflow when we
> can run jtreg tests with the static launcher - could be done in a later
> step;
> Step 3 - Remove all STATIC_BUILD macros in JDK runtime code; Also cleanup
> the macros in tests (can be done later)
>               CSR and JNI specification work to support
> JNI_OnLoad_<lib_name> and friends for JNI dynamic library and builtin
> library
> Step 4 - Build (makefile) changes to support linking .a and .so libraries
> using the same set of .o objects, to avoid compiling the .c/.c++ source
> twice
>
> Those lay the foundation for the hermetic Java work in mainline.
>
>> Are you saying now that the priorities has changed, and that you want to
>> start by introducing your framework for the runtime lookup if we are static
>> or dynamic?
>>
> By "runtime lookup", I think you were referring to the JNI native library
> lookup. We can handle them as part of the step 2 above.
>
> I think for any of the runtime changes, we need to be able to build in the
> mainline (although initially not included in the github workflow).
>
>>
>> To be honest, I think your prototype is rather hacky in how you implement
>> this, and I reckon that it will require quite a lot of work to be accepted
>> into mainline. I also think you need a CSR for changing the Hotspot/JDK
>> behavior wrt this, which further adds to the process.
>>
>
> For CSR work, we can do that as part of step #3. Actually, for the
> builtin/dynamic library lookup support, I think the enhancements in
> hermetic-java-runtime are already close to the proper shape (not hacky).
>
>
>> If you want to go that route instead, then I'll put my work on hold until
>> you have gotten a working solution for the runtime lookup in mainline. I
>> gather this means that there is no real stress for me anymore.
>>
> Ron and Alan mentioned Tuesday morning PT may not work the best for you.
> Would you be open for a separate time to discuss the details on moving
> forward?
>
> Best,
> Jiangli
>
>
>>
>> /Magnus
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240521/a1314803/attachment.htm>

From liangchenblue at gmail.com  Wed May 22 11:35:46 2024
From: liangchenblue at gmail.com (Chen Liang)
Date: Wed, 22 May 2024 06:35:46 -0500
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <580b3aacd8df48fcaae3399718e229ab@kth.se>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>
 <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
 <580b3aacd8df48fcaae3399718e229ab@kth.se>
Message-ID: <CABe8uE065Q3+0yNjtyDF-eJM4LN-MbY9kfC44CnSQ-KM4p862g@mail.gmail.com>

Hi Aman,
We have tried defining Proxy as hidden classes; a previous attempt was on
hold because of issues with serialization. Otherwise, Proxies work great as
hidden classes.

Chen

On Mon, May 20, 2024 at 7:56?AM Aman Sharma <amansha at kth.se> wrote:

> Hi David,
>
>
> > I would not expect any class load
> events.
>
>
> I understand. I also haven't tried to intercept them but I see only one
> approach right now to include them in an allowlist - 1) statically look for
> invocations of "Lookup::defineHiddenClass". 2) Instrument them so that
> its first argument "bytes" can be looked into upon. I haven't looked into
> it much because I did not have much idea about it. And they are hidden so
> it made it worse. ? Thanks for sharing the JEP!
>
>
> >
> java.lang.reflect.Proxy could define hidden classes to act as the proxy
> classes which implement proxy interfaces; from JEP 317
>
>
> It says that Proxy classes will also become hidden classes. Is it
> underway? Right now one can intercept, transform them, and include them in
> an allowlist. What do you think of naming them independent of AtomicLong so
> that a proxy class generated at runtime is easy to lookup in the allowlist?
>
>
>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> ------------------------------
> *From:* David Holmes <david.holmes at oracle.com>
> *Sent:* Monday, May 20, 2024 2:30:37 PM
> *To:* Aman Sharma; liangchenblue at gmail.com
> *Cc:* core-libs-dev at openjdk.org; leyden-dev at openjdk.org
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
>
> On 20/05/2024 10:12 pm, Aman Sharma wrote:
> > Hi David,
> >
> >
> >  > How did you try to intercept them? Hidden classes are not "loaded" in
> > the normal sense so won't trigger class load events.
> >
> >
> > I could not intercept them. I only see them when I pass `-verbose:class`
> > in the Java CLI.
>
> Yes that is why I asked how you tried to intercept them.
>
> >
> > I also couldn't intercept them using JVMTI Class File Load Hook
> > <
> https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook>
> event. However JEP 371 suggests that it should be possible to intercept
> them using JVMTI Class Load <
> https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad>
> event, but I won't have the bytecode at this stage. So is there no way to
> get its bytecode before it is linked and initialized in the JVM?
>
> Hidden classes are not loaded so I would not expect any class load
> events. However the exact nature of the JVMTI class load event is
> unclear as it talks about "class or interface creation" which is neither
> loading or defining per se. But a class prepare event sounds like it
> should be issued. However neither give you access to the bytecode of the
> class AFAICS.
>
> David
> -----
>
>
> >
> > Regards,
> > Aman Sharma
> >
> > PhD Student
> > KTH Royal Institute of Technology
> > School of Electrical Engineering and Computer Science (EECS)
> > Department of Theoretical Computer Science (TCS)
> > <
> http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha
> >
> > <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> > <https://algomaster99.github.io/>
> > ------------------------------------------------------------------------
> > *From:* David Holmes <david.holmes at oracle.com>
> > *Sent:* Monday, May 20, 2024 2:59:17 AM
> > *To:* Aman Sharma; liangchenblue at gmail.com
> > *Cc:* core-libs-dev at openjdk.org; leyden-dev at openjdk.org
> > *Subject:* Re: Deterministic naming of subclasses of
> > `java/lang/reflect/Proxy`
> > On 17/05/2024 9:43 pm, Aman Sharma wrote:
> >> Hi Chen,
> >>
> >>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
> >>
> >> I do see this as output when I pass -verbose:class. However, based on
> my
> >> experiments, I have seen that neither an agent passed via 'javaagent'
> >> nor an agent passed via 'agentpath' is able to intercept this hidden
> class.
> >
> > How did you try to intercept them? Hidden classes are not "loaded" in
> > the normal sense so won't trigger class load events.
> >
> >> Also, I was a bit confused since I saw somewhere that the names of
> >> hidden classes are null. But thanks for clarifying here.
> >
> > The JEP clearly defines the name format for hidden classes - though the
> > final component is VM specific (and typically a hashcode).
> >
> > https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
> >
> > Cheers,
> > David
> > -----
> >
> >>  > avoid dynamic class loading
> >>
> >> I don't see dynamic class loading as a problem. I only mind some
> >> unstable generation aspects of them which make it hard to verify them
> >> based on an allowlist.
> >>
> >> For example, if this hidden class is generated with the exact same name
> >> and the exact same bytecode during runtime as well, it would be easy to
> >> verify it. However, I do see the names are based on some sort of memory
> >> address so and I don't know what bytecode it has so I don't have
> >> suggestions to make them stable as of now. For Proxy classes, I feel it
> >> can be addressed unless you disagree or some involved in Project Leyden
> >> does. :) Thank you for forwarding my mail there.
> >>
> >> Regards,
> >> Aman Sharma
> >>
> >> PhD Student
> >> KTH Royal Institute of Technology
> >> https://algomaster99.github.io/ <https://algomaster99.github.io/>
> > <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
> >>
> >> ------------------------------------------------------------------------
> >> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
> >> *Sent:* Friday, May 17, 2024 1:23:58 pm
> >> *To:* Aman Sharma <amansha at kth.se>
> >> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>;
> >> leyden-dev at openjdk.org <leyden-dev at openjdk.org>
> >> *Subject:* Re: Deterministic naming of subclasses of
> >> `java/lang/reflect/Proxy`
> >>
> >> Hi Aman,
> >> For `-verbose:class`, it's a JVM argument instead of a program
> argument;
> >> so when you run a java program like `java Main`, you should call it as
> >> `java -verbose:class Main`.
> >> When done correctly, you should see hidden class outputs like:
> >> [0.032s][info][class,load]
> >> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
> >> __JVM_LookupDefineClass__
> >> The loading of java.lang.invoke hidden classes requires your program to
> >> use MethodHandle features, like a lambda.
> >>
> >> I think the problem you are exploring, that to avoid dynamic class
> >> loading and effectively turn Java Platform closed for security, is also
> >> being accomplished by project Leyden (as I've shared initially); Thus,
> I
> >> am forwarding this to leyden-dev instead, so you can see what approach
> >> Leyden uses to accomplish the same goal as yours.
> >>
> >> Regards, Chen Liang
> >>
> >> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se
> >> <mailto:amansha at kth.se <mailto:amansha at kth.se <amansha at kth.se>>>>
> wrote:
> >>
> >>     __
> >>
> >>     Hi Roger,
> >>
> >>
> >>     Do you have ideas on how to intercept them? My javaagent is not able
> >>     to nor a JVMTI agent passed using `agentpath` option. It also does
> >>     not seem to show up in logs when I pass `-verbose:class`.
> >>
> >>
> >>     Also, what do you think of renaming the proxy classes as suggested
> >>     below?
> >>
> >>
> >>     Regards,
> >>     Aman Sharma
> >>
> >>     PhD Student
> >>     KTH Royal Institute of Technology
> >>     School of Electrical Engineering and Computer Science (EECS)
> >>     Department of Theoretical Computer Science (TCS)
> >>     <http://www.kth.se><https://www.kth.se/profile/amansha><
> https://www.kth.se/profile/amansha <
> http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha
> >>
> >>     <https://www.kth.se/profile/amansha
> > <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> >>     <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
> >>
> ------------------------------------------------------------------------
> >>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org
> >>     <mailto:core-libs-dev-retn at openjdk.org
> > <mailto:core-libs-dev-retn at openjdk.org <core-libs-dev-retn at openjdk.org>>>>
> on behalf of Roger Riggs
> >>     <roger.riggs at oracle.com <mailto:roger.riggs at oracle.com <
> mailto:roger.riggs at oracle.com <roger.riggs at oracle.com>>>>
> >>     *Sent:* Friday, May 17, 2024 4:57:46 AM
> >>     *To:* core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org <
> mailto:core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>>>
> >>     *Subject:* Re: Deterministic naming of subclasses of
> >>     `java/lang/reflect/Proxy`
> >>     Hi Aman,
> >>
> >>     You may also run into hidden classes (JEP 371: Hidden Classes) that
> >>     allow classes to be defined, at runtime, without names.
> >>     It has been proposed to use them for generated proxies but that
> >>     hasn't been implemented yet.
> >>     There are benefits to having nameless classes, because they can't be
> >>     referenced by name, only as a capability, they can be better
> >>     encapsulated.
> >>
> >>     fyi, Roger Riggs
> >>
> >>
> >>     On 5/16/24 8:11 AM, Aman Sharma wrote:
> >>>
> >>>     Hi,
> >>>
> >>>
> >>>     Thanks for your response, Liang!
> >>>
> >>>
> >>>     > I think you meant CVE-2021-42392 instead of 2022.
> >>>
> >>>
> >>>     Sorry of the error. I indeed meant CVE-2021-42392
> >>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392
> > <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
> >>>
> >>>
> >>>     > Leyden mainly avoids this unstable generation by performing a
> >>>     training run to collect classes loaded
> >>>
> >>>
> >>>     Would love to know the details of Project Leyden and how they
> >>>     worked so far to focus on this goal. In our case, the training run
> >>>     is the test suite.
> >>>
> >>>
> >>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
> >>>     in Java 18
> >>>
> >>>
> >>>     I did see them not appearing in my allowlist when I ran my study
> >>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
> >>>     about this JEP. I see they are re-implemented with method handles.
> >>>
> >>>
> >>>     > How are you checking the classes?
> >>>
> >>>
> >>>     To detect runtime generated code, we have javaagent that is hooked
> >>>     statically to the test suite execution. It gives us all classes
> >>>     that that is loaded post the JVM and the javaagent are loaded. So
> >>>     we only check the classes loaded for the purpose of running the
> >>>     application. This is also why we did not choose -agentlib as it
> >>>     would give classes for the setting up JVM and javaagent and we the
> >>>     user of our tool must the classes they load.
> >>>
> >>>
> >>>     Next, we have a `ClassFileTransformer` hook in the agent where we
> >>>     produce the checksum using the bytecode. And we compare the
> >>>     checksum with the one existing in the allowlist. The checksum
> >>>     computation algorithm is same for both steps. Let me describe how
> >>>     I compute the checksum.
> >>>
> >>>
> >>>      1. I get the CONSTANT_Class_info
> >>>         <
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1
> <
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>>
> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7
> <
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>>
> corresponding to a fix String constant, say "foo".
> >>>      2. Since, the name of the class is used to refer to its types
> >>>         members (fields/method), I get all CONSTANT_Fieldref_info
> >>>         <
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2
> <
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>>
> and if its `class_index` corresponds to the old `this_class`, we rewrite
> the UTF8 value of class_index to the same constant "foo".
> >>>      3. Next, since the naming of the fields, in Proxy classes, are
> >>>         also suffixed by numbers, for example, `private static Method
> >>>         m4`, we rewrite the UTF8 value of name in the
> >>>         CONSTANT_NameAndType_info
> >>>         <
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6
> <
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6
> >>.
> >>>      4. These fields can also have a random order so we simply sort
> >>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
> >>>         any differences due to ordering of fields/methods.
> >>>      5. Simply sorting the byte array still had minute differences. I
> >>>         could not understand why they existed even though values in
> >>>         constant pool of the bytecode in allowlist and at runtime were
> >>>         exactly the same after rewriting. The differences existed in
> >>>         the bytes of the Code attribute of methods. I concluded that
> >>>         the bytes stored some position information. To avoid this, I
> >>>         created a subarray where I considered the bytes corresponding
> >>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
> >>>         it resulted in the same checksums for both classfiles.
> >>>
> >>>
> >>>     Let's understand the whole approach with an example of Proxy class.
> >>>
> >>>     `
> >>>     public  final  class  $Proxy42  extends  Proxy  implements
> org.apache.logging.log4j.core.config.plugins.Plugin  {
> >>>     `
> >>>
> >>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
> >>>
> >>>     When the same class is intercepted at runtime, say "$Proxy10", we
> >>>     look for "Proxy_Plugin" in the allowlist and since the checksum
> >>>     algorithm is same in both cases, we get a match and let the class
> >>>     load.
> >>>
> >>>     This approach has seemed to work well for Proxy classes, Generated
> >>>     Constructor Accessor (which is removed as you said). I also looked
> >>>     at the species generated by method handles. I did not notice any
> >>>     modification in them. Their name generation seemed okay to me. If
> >>>     some new Species are generated, it is of course detected since it
> >>>     is not in the allowlist.
> >>>
> >>>     I have not looked into LambdaMetafactory because I did not
> >>>     encounter it as a problem so far, but I am aware its name
> >>>     generation is also unstable. I have run my approach only a few
> >>>     projects only. And for hidden classes, I assume the the agent
> >>>     won't be able to intercept them so detecting them would be really
> >>>     hard.
> >>>
> >>>
> >>>     Regards,
> >>>     Aman Sharma
> >>>
> >>>     PhD Student
> >>>     KTH Royal Institute of Technology
> >>>     School of Electrical Engineering and Computer Science (EECS)
> >>>     Department of Theoretical Computer Science (TCS)
> >>>     <https://www.kth.se/profile/amansha
> > <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> > <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
> >>>
> ------------------------------------------------------------------------
> >>>     *From:* liangchenblue at gmail.com <mailto:liangchenblue at gmail.com <
> mailto:liangchenblue at gmail.com <liangchenblue at gmail.com>>>
> >>>     <liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com <
> mailto:liangchenblue at gmail.com <liangchenblue at gmail.com>>>
> >>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
> >>>     *To:* Aman Sharma; core-libs-dev
> >>>     *Cc:* Martin Monperrus
> >>>     *Subject:* Re: Deterministic naming of subclasses of
> >>>     `java/lang/reflect/Proxy`
> >>>     Hi Aman,
> >>>     I think you meant CVE-2021-42392 instead of 2022.
> >>>
> >>>     For your approach of an "allowlist" for Java runtime, project
> >>>     Leyden is looking to generate a static image [1], that
> >>>     > At run time it cannot load classes from outside the image, nor
> >>>     can it create classes dynamically.
> >>>     Leyden mainly avoids this unstable generation by performing a
> >>>     training run to collect classes loaded and even object graphs; I
> >>>     am not familiar with the details unfortunately.
> >>>
> >>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
> >>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
> >>>     replying this thread to core-libs-dev.
> >>>
> >>>     For your perceived problem that classes don't have unique names,
> >>>     your description sounds dubious: GeneratedConstructorAccessor is
> >>>     already retired by JEP 416 [2] in Java 18, and there are many
> >>>     other cases in which JDK generates classes without stable names,
> >>>     notoriously LambdaMetafactory (Gradle wished for cacheable
> >>>     Lambdas); the same applies for the generated classes for
> >>>     MethodHandle's LambdaForms (which carries implementation code for
> >>>     LambdaForm). How are you checking the classes? It seems you are
> >>>     not checking hidden classes. Proxy and Lambda classes are defined
> >>>     by the caller's class loader, while LambdaForms are under JDK's
> >>>     system class loader I think. We need to ensure you are correctly
> >>>     finding all unstable classes before we can proceed.
> >>>
> >>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
> > <https://openjdk.org/projects/leyden/notes/01-beginnings>
> >>>     <https://openjdk.org/projects/leyden/notes/01-beginnings
> > <https://openjdk.org/projects/leyden/notes/01-beginnings>>
> >>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
> > <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
> >>>
> >>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se
> >>>     <mailto:amansha at kth.se <mailto:amansha at kth.se <amansha at kth.se>>>>
> wrote:
> >>>
> >>>         Hi,
> >>>
> >>>
> >>>         My name is Aman and I am a PhD student at KTH Royal Institute
> >>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
> >>>         <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>>
> project to
> > strengthen the
> >>>         software supply chain of multiple ecosystem. I particularly
> >>>         focus on runtime integrity in Java. In this email, I want to
> >>>         write about an issue I have discovered with /dynamic
> >>>         generation of `java.lang.reflect.Proxy`classes/. I will
> >>>         propose a solution and would love to hear the feedback from
> >>>         the community. Let me know if this is the correct mailing-list
> >>>         for such discussions. It seemed the most relevant from this
> >>>         list <https://mail.openjdk.org/mailman/listinfo
> > <https://mail.openjdk.org/mailman/listinfo>>.
> >>>
> >>>
> >>>         *My research*
> >>>
> >>>         *
> >>>         *
> >>>
> >>>         Java has features to load class on the fly - it can either
> >>>         download or generate a class at runtime. These features are
> >>>         useful for inner workings of JDK. For example, implementing
> >>>         annotations, reflective access, etc. However, these features
> >>>         have also contributed to critical vulnerabilities in the past
> >>>         - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
> >>>         All of these vulnerabilities have one thing in common - /a
> >>>         class that was not known during build time was
> >>>         downloaded/generated at runtime and loaded into JVM./
> >>>
> >>>
> >>>         To defend against such vulnerabilities, we propose a solution
> >>>         to /allowlist classes for runtime/. This allowlist will
> >>>         contain an exhaustive list of classes that can be loaded by
> >>>         the JVM and it will be enforced at runtime. We build this
> >>>         allowlist from three sources:
> >>>
> >>>          1. All classes of all modules provided by the Java Standard
> >>>             Library. We use ClassGraph
> >>>             <https://github.com/classgraph/classgraph
> > <https://github.com/classgraph/classgraph>> to scan the JDK.
> >>>          2. We can take the source code and all dependencies of an
> >>>             application. We use a software bill of materials to get
> >>>             all the data.
> >>>          3. Finally, we use run the test suite to include any runtime
> >>>             downloaded/generated classes.
> >>>
> >>>         Such a list is able to prevent the above 3 CVEs because it
> >>>         does not let the "unknown" bytecode to be loaded.
> >>>
> >>>         *Problem with generating such an allowlist*
> >>>         *
> >>>         *
> >>>         The first two parts of the allowlist are easy to get. The
> >>>         problem is with the third step where we want to allowlist all
> >>>         the classes that could be downloaded or generated. Upon
> >>>         running the test suite and hooking to the classes it loads, we
> >>>         observer that the list consists of classes that are called
> >>>         "com/sun/proxy/$Proxy2",
> >>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
> >>>         many more. The purpose of these classes can be identifed. The
> >>>         proxy class is created for to implement an annotation. The
> >>>         accessor gives access to constructor of a class to the JVM.
> >>>
> >>>         When enforcing this allowlist at runtime, we see that the
> >>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
> >>>         allowlist and at runtime. In our case, we we are experimenting
> >>>         with pdfbox <https://github.com/apache/pdfbox <
> https://github.com/apache/pdfbox>> so
> > we created
> >>>         the allowlist using its test suite. Then we enforced this
> >>>         allowlist while running some of its subcommands. However,
> >>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
> >>>         at runtime that implemented the same interfaces and had the
> >>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
> >>>         only differed in the name of the class, order of fields, and
> >>>         types for fields references. This could happen because the
> >>>         order of the loading of class is workload dependent, but it
> >>>         causes problem to generate such an allowlist.
> >>>
> >>>         *Solution
> >>>         *
> >>>
> >>>
> >>>         We propose that naming of subclasses of
> >>>         "java/lang/reflect/Proxy" should not be dependent upon the
> >>>         order of loading. In order to do so, two issues can be fixed:
> >>>
> >>>          1. The naming of the class should not be based on AtomicLong
> >>>             <
> https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531
> <
> https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>>.
> Rather it could be named based on the interfaces it implements. I also
> wonder why AtomicLong is chosen in the first place.
> >>>          2. Methods of the interfaces must be in a particular order.
> >>>             Right now, they are not sorted in any particular order
> >>>             <
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178
> <
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178
> >>.
> >>>
> >>>
> >>>         These fixes will make proxy class generation deterministic
> >>>         with respect to order of loading and won't be flagged at
> >>>         runtime since the test suite would already detect them.
> >>>
> >>>         I would love to hear from the community about these ideas. If
> >>>         in agreement, I would be happy to produce a patch. I have
> >>>         discovered this issue with subclasses of
> >>>         GeneratedConstructorAccessor
> >>>         <
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java
> <
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>>
> as well and I imagine it will also apply to some other runtime generated
> classes. If you disagree, please let me know also. It helps with my
> research.
> >>>
> >>>         I also have PoCs for the above CVEs
> >>>         <https://github.com/chains-project/exploits-for-sbom.exe
> > <https://github.com/chains-project/exploits-for-sbom.exe>> and
> >>>         a proof concept tool is being developed under the name
> >>>         sbom.exe <https://github.com/chains-project/sbom.exe
> > <https://github.com/chains-project/sbom.exe>> in case
> >>>         any one wonders about the implementation. I would also be
> >>>         happy to explain more.
> >>>
> >>>         Regards,
> >>>         Aman Sharma
> >>>
> >>>         PhD Student
> >>>         KTH Royal Institute of Technology
> >>>         School of Electrical Engineering and Computer Science (EECS)
> >>>         Department of Theoretical Computer Science (TCS)
> >>>         <https://www.kth.se/profile/amansha
> > <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> > <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
> >>>
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240522/2dd4a473/attachment.htm>

From amansha at kth.se  Wed May 22 14:12:19 2024
From: amansha at kth.se (Aman Sharma)
Date: Wed, 22 May 2024 14:12:19 +0000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <CABe8uE065Q3+0yNjtyDF-eJM4LN-MbY9kfC44CnSQ-KM4p862g@mail.gmail.com>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>
 <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
 <580b3aacd8df48fcaae3399718e229ab@kth.se>,
 <CABe8uE065Q3+0yNjtyDF-eJM4LN-MbY9kfC44CnSQ-KM4p862g@mail.gmail.com>
Message-ID: <b64077d6cf0045e98b630cf888785182@kth.se>

Hi Chen,


That's clear. Thanks for letting me know. I guess then Project Leyden is working on naming the hidden classes deterministically to achieve their goals<https://openjdk.org/projects/leyden/notes/01-beginnings>.


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Chen Liang <liangchenblue at gmail.com>
Sent: Wednesday, May 22, 2024 1:35:46 PM
To: Aman Sharma
Cc: David Holmes; core-libs-dev at openjdk.org; leyden-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,
We have tried defining Proxy as hidden classes; a previous attempt was on hold because of issues with serialization. Otherwise, Proxies work great as hidden classes.

Chen

On Mon, May 20, 2024 at 7:56?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi David,


> I would not expect any class load
events.


I understand. I also haven't tried to intercept them but I see only one approach right now to include them in an allowlist - 1) statically look for invocations of "Lookup::defineHiddenClass". 2) Instrument them so that its first argument "bytes" can be looked into upon. I haven't looked into it much because I did not have much idea about it. And they are hidden so it made it worse. ? Thanks for sharing the JEP!


>

java.lang.reflect.Proxy could define hidden classes to act as the proxy classes which implement proxy interfaces; from JEP 317


It says that Proxy classes will also become hidden classes. Is it underway? Right now one can intercept, transform them, and include them in an allowlist. What do you think of naming them independent of AtomicLong so that a proxy class generated at runtime is easy to lookup in the allowlist?



Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
Sent: Monday, May 20, 2024 2:30:37 PM
To: Aman Sharma; liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

On 20/05/2024 10:12 pm, Aman Sharma wrote:
> Hi David,
>
>
>  > How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>
> I could not intercept them. I only see them when I pass `-verbose:class`
> in the Java CLI.

Yes that is why I asked how you tried to intercept them.

>
> I also couldn't intercept them using JVMTI Class File Load Hook
> <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook> event. However JEP 371 suggests that it should be possible to intercept them using JVMTI Class Load <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad> event, but I won't have the bytecode at this stage. So is there no way to get its bytecode before it is linked and initialized in the JVM?

Hidden classes are not loaded so I would not expect any class load
events. However the exact nature of the JVMTI class load event is
unclear as it talks about "class or interface creation" which is neither
loading or defining per se. But a class prepare event sounds like it
should be issued. However neither give you access to the bytecode of the
class AFAICS.

David
-----


>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> <https://algomaster99.github.io/>
> ------------------------------------------------------------------------
> *From:* David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
> *Sent:* Monday, May 20, 2024 2:59:17 AM
> *To:* Aman Sharma; liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>
> *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
> On 17/05/2024 9:43 pm, Aman Sharma wrote:
>> Hi Chen,
>>
>>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
>>
>> I do see this as output when I pass -verbose:class. However, based on my
>> experiments, I have seen that neither an agent passed via 'javaagent'
>> nor an agent passed via 'agentpath' is able to intercept this hidden class.
>
> How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>> Also, I was a bit confused since I saw somewhere that the names of
>> hidden classes are null. But thanks for clarifying here.
>
> The JEP clearly defines the name format for hidden classes - though the
> final component is VM specific (and typically a hashcode).
>
> https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
>
> Cheers,
> David
> -----
>
>>  > avoid dynamic class loading
>>
>> I don't see dynamic class loading as a problem. I only mind some
>> unstable generation aspects of them which make it hard to verify them
>> based on an allowlist.
>>
>> For example, if this hidden class is generated with the exact same name
>> and the exact same bytecode during runtime as well, it would be easy to
>> verify it. However, I do see the names are based on some sort of memory
>> address so and I don't know what bytecode it has so I don't have
>> suggestions to make them stable as of now. For Proxy classes, I feel it
>> can be addressed unless you disagree or some involved in Project Leyden
>> does. :) Thank you for forwarding my mail there.
>>
>> Regards,
>> Aman Sharma
>>
>> PhD Student
>> KTH Royal Institute of Technology
>> https://algomaster99.github.io/ <https://algomaster99.github.io/>
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>
>> ------------------------------------------------------------------------
>> *From:* liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
>> *Sent:* Friday, May 17, 2024 1:23:58 pm
>> *To:* Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>>
>> *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>;
>> leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org> <leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>>
>> *Subject:* Re: Deterministic naming of subclasses of
>> `java/lang/reflect/Proxy`
>>
>> Hi Aman,
>> For `-verbose:class`, it's a JVM argument instead of a program argument;
>> so when you run a java program like `java Main`, you should call it as
>> `java -verbose:class Main`.
>> When done correctly, you should see hidden class outputs like:
>> [0.032s][info][class,load]
>> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
>> __JVM_LookupDefineClass__
>> The loading of java.lang.invoke hidden classes requires your program to
>> use MethodHandle features, like a lambda.
>>
>> I think the problem you are exploring, that to avoid dynamic class
>> loading and effectively turn Java Platform closed for security, is also
>> being accomplished by project Leyden (as I've shared initially); Thus, I
>> am forwarding this to leyden-dev instead, so you can see what approach
>> Leyden uses to accomplish the same goal as yours.
>>
>> Regards, Chen Liang
>>
>> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>
>> <mailto:amansha at kth.se<mailto:amansha at kth.se> <mailto:amansha at kth.se>>> wrote:
>>
>>     __
>>
>>     Hi Roger,
>>
>>
>>     Do you have ideas on how to intercept them? My javaagent is not able
>>     to nor a JVMTI agent passed using `agentpath` option. It also does
>>     not seem to show up in logs when I pass `-verbose:class`.
>>
>>
>>     Also, what do you think of renaming the proxy classes as suggested
>>     below?
>>
>>
>>     Regards,
>>     Aman Sharma
>>
>>     PhD Student
>>     KTH Royal Institute of Technology
>>     School of Electrical Engineering and Computer Science (EECS)
>>     Department of Theoretical Computer Science (TCS)
>>     <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>>
>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>>     <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>     ------------------------------------------------------------------------
>>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>
>>     <mailto:core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>
> <mailto:core-libs-dev-retn at openjdk.org>>> on behalf of Roger Riggs
>>     <roger.riggs at oracle.com<mailto:roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com<mailto:roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com>>>
>>     *Sent:* Friday, May 17, 2024 4:57:46 AM
>>     *To:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org>>
>>     *Subject:* Re: Deterministic naming of subclasses of
>>     `java/lang/reflect/Proxy`
>>     Hi Aman,
>>
>>     You may also run into hidden classes (JEP 371: Hidden Classes) that
>>     allow classes to be defined, at runtime, without names.
>>     It has been proposed to use them for generated proxies but that
>>     hasn't been implemented yet.
>>     There are benefits to having nameless classes, because they can't be
>>     referenced by name, only as a capability, they can be better
>>     encapsulated.
>>
>>     fyi, Roger Riggs
>>
>>
>>     On 5/16/24 8:11 AM, Aman Sharma wrote:
>>>
>>>     Hi,
>>>
>>>
>>>     Thanks for your response, Liang!
>>>
>>>
>>>     > I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>
>>>     Sorry of the error. I indeed meant CVE-2021-42392
>>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392
> <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
>>>
>>>
>>>     > Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded
>>>
>>>
>>>     Would love to know the details of Project Leyden and how they
>>>     worked so far to focus on this goal. In our case, the training run
>>>     is the test suite.
>>>
>>>
>>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>>>     in Java 18
>>>
>>>
>>>     I did see them not appearing in my allowlist when I ran my study
>>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
>>>     about this JEP. I see they are re-implemented with method handles.
>>>
>>>
>>>     > How are you checking the classes?
>>>
>>>
>>>     To detect runtime generated code, we have javaagent that is hooked
>>>     statically to the test suite execution. It gives us all classes
>>>     that that is loaded post the JVM and the javaagent are loaded. So
>>>     we only check the classes loaded for the purpose of running the
>>>     application. This is also why we did not choose -agentlib as it
>>>     would give classes for the setting up JVM and javaagent and we the
>>>     user of our tool must the classes they load.
>>>
>>>
>>>     Next, we have a `ClassFileTransformer` hook in the agent where we
>>>     produce the checksum using the bytecode. And we compare the
>>>     checksum with the one existing in the allowlist. The checksum
>>>     computation algorithm is same for both steps. Let me describe how
>>>     I compute the checksum.
>>>
>>>
>>>      1. I get the CONSTANT_Class_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>> corresponding to a fix String constant, say "foo".
>>>      2. Since, the name of the class is used to refer to its types
>>>         members (fields/method), I get all CONSTANT_Fieldref_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
>>>      3. Next, since the naming of the fields, in Proxy classes, are
>>>         also suffixed by numbers, for example, `private static Method
>>>         m4`, we rewrite the UTF8 value of name in the
>>>         CONSTANT_NameAndType_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>>.
>>>      4. These fields can also have a random order so we simply sort
>>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
>>>         any differences due to ordering of fields/methods.
>>>      5. Simply sorting the byte array still had minute differences. I
>>>         could not understand why they existed even though values in
>>>         constant pool of the bytecode in allowlist and at runtime were
>>>         exactly the same after rewriting. The differences existed in
>>>         the bytes of the Code attribute of methods. I concluded that
>>>         the bytes stored some position information. To avoid this, I
>>>         created a subarray where I considered the bytes corresponding
>>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>>>         it resulted in the same checksums for both classfiles.
>>>
>>>
>>>     Let's understand the whole approach with an example of Proxy class.
>>>
>>>     `
>>>     public  final  class  $Proxy42  extends  Proxy  implements  org.apache.logging.log4j.core.config.plugins.Plugin  {
>>>     `
>>>
>>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>>>
>>>     When the same class is intercepted at runtime, say "$Proxy10", we
>>>     look for "Proxy_Plugin" in the allowlist and since the checksum
>>>     algorithm is same in both cases, we get a match and let the class
>>>     load.
>>>
>>>     This approach has seemed to work well for Proxy classes, Generated
>>>     Constructor Accessor (which is removed as you said). I also looked
>>>     at the species generated by method handles. I did not notice any
>>>     modification in them. Their name generation seemed okay to me. If
>>>     some new Species are generated, it is of course detected since it
>>>     is not in the allowlist.
>>>
>>>     I have not looked into LambdaMetafactory because I did not
>>>     encounter it as a problem so far, but I am aware its name
>>>     generation is also unstable. I have run my approach only a few
>>>     projects only. And for hidden classes, I assume the the agent
>>>     won't be able to intercept them so detecting them would be really
>>>     hard.
>>>
>>>
>>>     Regards,
>>>     Aman Sharma
>>>
>>>     PhD Student
>>>     KTH Royal Institute of Technology
>>>     School of Electrical Engineering and Computer Science (EECS)
>>>     Department of Theoretical Computer Science (TCS)
>>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>     ------------------------------------------------------------------------
>>>     *From:* liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>>
>>>     <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>> <mailto:liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>>
>>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
>>>     *To:* Aman Sharma; core-libs-dev
>>>     *Cc:* Martin Monperrus
>>>     *Subject:* Re: Deterministic naming of subclasses of
>>>     `java/lang/reflect/Proxy`
>>>     Hi Aman,
>>>     I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>     For your approach of an "allowlist" for Java runtime, project
>>>     Leyden is looking to generate a static image [1], that
>>>     > At run time it cannot load classes from outside the image, nor
>>>     can it create classes dynamically.
>>>     Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded and even object graphs; I
>>>     am not familiar with the details unfortunately.
>>>
>>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
>>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
>>>     replying this thread to core-libs-dev.
>>>
>>>     For your perceived problem that classes don't have unique names,
>>>     your description sounds dubious: GeneratedConstructorAccessor is
>>>     already retired by JEP 416 [2] in Java 18, and there are many
>>>     other cases in which JDK generates classes without stable names,
>>>     notoriously LambdaMetafactory (Gradle wished for cacheable
>>>     Lambdas); the same applies for the generated classes for
>>>     MethodHandle's LambdaForms (which carries implementation code for
>>>     LambdaForm). How are you checking the classes? It seems you are
>>>     not checking hidden classes. Proxy and Lambda classes are defined
>>>     by the caller's class loader, while LambdaForms are under JDK's
>>>     system class loader I think. We need to ensure you are correctly
>>>     finding all unstable classes before we can proceed.
>>>
>>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>
>>>     <https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>>
>>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
> <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
>>>
>>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>
>>>     <mailto:amansha at kth.se<mailto:amansha at kth.se> <mailto:amansha at kth.se>>> wrote:
>>>
>>>         Hi,
>>>
>>>
>>>         My name is Aman and I am a PhD student at KTH Royal Institute
>>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
>>>         <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>> project to
> strengthen the
>>>         software supply chain of multiple ecosystem. I particularly
>>>         focus on runtime integrity in Java. In this email, I want to
>>>         write about an issue I have discovered with /dynamic
>>>         generation of `java.lang.reflect.Proxy`classes/. I will
>>>         propose a solution and would love to hear the feedback from
>>>         the community. Let me know if this is the correct mailing-list
>>>         for such discussions. It seemed the most relevant from this
>>>         list <https://mail.openjdk.org/mailman/listinfo
> <https://mail.openjdk.org/mailman/listinfo>>.
>>>
>>>
>>>         *My research*
>>>
>>>         *
>>>         *
>>>
>>>         Java has features to load class on the fly - it can either
>>>         download or generate a class at runtime. These features are
>>>         useful for inner workings of JDK. For example, implementing
>>>         annotations, reflective access, etc. However, these features
>>>         have also contributed to critical vulnerabilities in the past
>>>         - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
>>>         All of these vulnerabilities have one thing in common - /a
>>>         class that was not known during build time was
>>>         downloaded/generated at runtime and loaded into JVM./
>>>
>>>
>>>         To defend against such vulnerabilities, we propose a solution
>>>         to /allowlist classes for runtime/. This allowlist will
>>>         contain an exhaustive list of classes that can be loaded by
>>>         the JVM and it will be enforced at runtime. We build this
>>>         allowlist from three sources:
>>>
>>>          1. All classes of all modules provided by the Java Standard
>>>             Library. We use ClassGraph
>>>             <https://github.com/classgraph/classgraph
> <https://github.com/classgraph/classgraph>> to scan the JDK.
>>>          2. We can take the source code and all dependencies of an
>>>             application. We use a software bill of materials to get
>>>             all the data.
>>>          3. Finally, we use run the test suite to include any runtime
>>>             downloaded/generated classes.
>>>
>>>         Such a list is able to prevent the above 3 CVEs because it
>>>         does not let the "unknown" bytecode to be loaded.
>>>
>>>         *Problem with generating such an allowlist*
>>>         *
>>>         *
>>>         The first two parts of the allowlist are easy to get. The
>>>         problem is with the third step where we want to allowlist all
>>>         the classes that could be downloaded or generated. Upon
>>>         running the test suite and hooking to the classes it loads, we
>>>         observer that the list consists of classes that are called
>>>         "com/sun/proxy/$Proxy2",
>>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>>>         many more. The purpose of these classes can be identifed. The
>>>         proxy class is created for to implement an annotation. The
>>>         accessor gives access to constructor of a class to the JVM.
>>>
>>>         When enforcing this allowlist at runtime, we see that the
>>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
>>>         allowlist and at runtime. In our case, we we are experimenting
>>>         with pdfbox <https://github.com/apache/pdfbox <https://github.com/apache/pdfbox>> so
> we created
>>>         the allowlist using its test suite. Then we enforced this
>>>         allowlist while running some of its subcommands. However,
>>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
>>>         at runtime that implemented the same interfaces and had the
>>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>>>         only differed in the name of the class, order of fields, and
>>>         types for fields references. This could happen because the
>>>         order of the loading of class is workload dependent, but it
>>>         causes problem to generate such an allowlist.
>>>
>>>         *Solution
>>>         *
>>>
>>>
>>>         We propose that naming of subclasses of
>>>         "java/lang/reflect/Proxy" should not be dependent upon the
>>>         order of loading. In order to do so, two issues can be fixed:
>>>
>>>          1. The naming of the class should not be based on AtomicLong
>>>             <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531 <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
>>>          2. Methods of the interfaces must be in a particular order.
>>>             Right now, they are not sorted in any particular order
>>>             <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178 <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>>.
>>>
>>>
>>>         These fixes will make proxy class generation deterministic
>>>         with respect to order of loading and won't be flagged at
>>>         runtime since the test suite would already detect them.
>>>
>>>         I would love to hear from the community about these ideas. If
>>>         in agreement, I would be happy to produce a patch. I have
>>>         discovered this issue with subclasses of
>>>         GeneratedConstructorAccessor
>>>         <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.
>>>
>>>         I also have PoCs for the above CVEs
>>>         <https://github.com/chains-project/exploits-for-sbom.exe
> <https://github.com/chains-project/exploits-for-sbom.exe>> and
>>>         a proof concept tool is being developed under the name
>>>         sbom.exe <https://github.com/chains-project/sbom.exe
> <https://github.com/chains-project/sbom.exe>> in case
>>>         any one wonders about the implementation. I would also be
>>>         happy to explain more.
>>>
>>>         Regards,
>>>         Aman Sharma
>>>
>>>         PhD Student
>>>         KTH Royal Institute of Technology
>>>         School of Electrical Engineering and Computer Science (EECS)
>>>         Department of Theoretical Computer Science (TCS)
>>>         <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240522/678ec047/attachment.htm>

From amansha at kth.se  Wed May 22 18:19:41 2024
From: amansha at kth.se (Aman Sharma)
Date: Wed, 22 May 2024 18:19:41 +0000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <b64077d6cf0045e98b630cf888785182@kth.se>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>
 <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
 <580b3aacd8df48fcaae3399718e229ab@kth.se>,
 <CABe8uE065Q3+0yNjtyDF-eJM4LN-MbY9kfC44CnSQ-KM4p862g@mail.gmail.com>,
 <b64077d6cf0045e98b630cf888785182@kth.se>
Message-ID: <eabfa5ae508e4257bd0c9bbef244637f@kth.se>

Hi,


Another thing I wanted to look into in this thread was the order of fields in the Proxy classes generated. They are also based on the a number. The same proxy classes across different executions can have random order of `Method` fields and the methods could be mapped to different field names.


For example, consider the proxy class based on `picocli.CommandLine<https://github.com/remkop/picocli/blob/da98db63d1b516141b7485881b0dcddfd082dbc8/src/main/java/picocli/CommandLine.java#L4541>` in two different executions.

// fields and method are truncated for brevity
public final class $Proxy9 extends Proxy implements CommandLine.Command {
    private static Method m1;
    private static Method m32;
    private static Method m21;
    private static Method m43;
    private static Method m36;
    private static Method m27;

    public final boolean helpCommand() throws  {
        try {
            return (Boolean)super.h.invoke(this, m32, (Object[])null);
        } catch (RuntimeException | Error var2) {
            throw var2;
        } catch (Throwable var3) {
            throw new UndeclaredThrowableException(var3);
        }
     }

// fields and method are truncated for brevity
public final class $Proxy13 extends Proxy implements CommandLine.Command {
    private static Method m1;
    private static Method m29;
    private static Method m16;
    private static Method m40;
    private static Method m38;
    private static Method m12;

    public final boolean helpCommand() throws  {
        try {
            return (Boolean)super.h.invoke(this, m29, (Object[])null);
        } catch (RuntimeException | Error var2) {
            throw var2;
        } catch (Throwable var3) {
            throw new UndeclaredThrowableException(var3);
        }
    }


Notice the difference in the order of fields and `helpCommand` method is mapped to a different field name in both classes. This happens because the method array returned by `getMethods` is not sorted in any particular order<https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178> when generating a proxy class. What dictates this order? And why is it not deterministic?


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Aman Sharma
Sent: Wednesday, May 22, 2024 4:12:19 PM
To: Chen Liang
Cc: David Holmes; core-libs-dev at openjdk.org; leyden-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`


Hi Chen,


That's clear. Thanks for letting me know. I guess then Project Leyden is working on naming the hidden classes deterministically to achieve their goals<https://openjdk.org/projects/leyden/notes/01-beginnings>.


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Chen Liang <liangchenblue at gmail.com>
Sent: Wednesday, May 22, 2024 1:35:46 PM
To: Aman Sharma
Cc: David Holmes; core-libs-dev at openjdk.org; leyden-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,
We have tried defining Proxy as hidden classes; a previous attempt was on hold because of issues with serialization. Otherwise, Proxies work great as hidden classes.

Chen

On Mon, May 20, 2024 at 7:56?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi David,


> I would not expect any class load
events.


I understand. I also haven't tried to intercept them but I see only one approach right now to include them in an allowlist - 1) statically look for invocations of "Lookup::defineHiddenClass". 2) Instrument them so that its first argument "bytes" can be looked into upon. I haven't looked into it much because I did not have much idea about it. And they are hidden so it made it worse. ? Thanks for sharing the JEP!


>

java.lang.reflect.Proxy could define hidden classes to act as the proxy classes which implement proxy interfaces; from JEP 317


It says that Proxy classes will also become hidden classes. Is it underway? Right now one can intercept, transform them, and include them in an allowlist. What do you think of naming them independent of AtomicLong so that a proxy class generated at runtime is easy to lookup in the allowlist?



Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
Sent: Monday, May 20, 2024 2:30:37 PM
To: Aman Sharma; liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

On 20/05/2024 10:12 pm, Aman Sharma wrote:
> Hi David,
>
>
>  > How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>
> I could not intercept them. I only see them when I pass `-verbose:class`
> in the Java CLI.

Yes that is why I asked how you tried to intercept them.

>
> I also couldn't intercept them using JVMTI Class File Load Hook
> <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook> event. However JEP 371 suggests that it should be possible to intercept them using JVMTI Class Load <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad> event, but I won't have the bytecode at this stage. So is there no way to get its bytecode before it is linked and initialized in the JVM?

Hidden classes are not loaded so I would not expect any class load
events. However the exact nature of the JVMTI class load event is
unclear as it talks about "class or interface creation" which is neither
loading or defining per se. But a class prepare event sounds like it
should be issued. However neither give you access to the bytecode of the
class AFAICS.

David
-----


>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> <https://algomaster99.github.io/>
> ------------------------------------------------------------------------
> *From:* David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
> *Sent:* Monday, May 20, 2024 2:59:17 AM
> *To:* Aman Sharma; liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>
> *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
> On 17/05/2024 9:43 pm, Aman Sharma wrote:
>> Hi Chen,
>>
>>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
>>
>> I do see this as output when I pass -verbose:class. However, based on my
>> experiments, I have seen that neither an agent passed via 'javaagent'
>> nor an agent passed via 'agentpath' is able to intercept this hidden class.
>
> How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>> Also, I was a bit confused since I saw somewhere that the names of
>> hidden classes are null. But thanks for clarifying here.
>
> The JEP clearly defines the name format for hidden classes - though the
> final component is VM specific (and typically a hashcode).
>
> https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
>
> Cheers,
> David
> -----
>
>>  > avoid dynamic class loading
>>
>> I don't see dynamic class loading as a problem. I only mind some
>> unstable generation aspects of them which make it hard to verify them
>> based on an allowlist.
>>
>> For example, if this hidden class is generated with the exact same name
>> and the exact same bytecode during runtime as well, it would be easy to
>> verify it. However, I do see the names are based on some sort of memory
>> address so and I don't know what bytecode it has so I don't have
>> suggestions to make them stable as of now. For Proxy classes, I feel it
>> can be addressed unless you disagree or some involved in Project Leyden
>> does. :) Thank you for forwarding my mail there.
>>
>> Regards,
>> Aman Sharma
>>
>> PhD Student
>> KTH Royal Institute of Technology
>> https://algomaster99.github.io/ <https://algomaster99.github.io/>
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>
>> ------------------------------------------------------------------------
>> *From:* liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
>> *Sent:* Friday, May 17, 2024 1:23:58 pm
>> *To:* Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>>
>> *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>;
>> leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org> <leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>>
>> *Subject:* Re: Deterministic naming of subclasses of
>> `java/lang/reflect/Proxy`
>>
>> Hi Aman,
>> For `-verbose:class`, it's a JVM argument instead of a program argument;
>> so when you run a java program like `java Main`, you should call it as
>> `java -verbose:class Main`.
>> When done correctly, you should see hidden class outputs like:
>> [0.032s][info][class,load]
>> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
>> __JVM_LookupDefineClass__
>> The loading of java.lang.invoke hidden classes requires your program to
>> use MethodHandle features, like a lambda.
>>
>> I think the problem you are exploring, that to avoid dynamic class
>> loading and effectively turn Java Platform closed for security, is also
>> being accomplished by project Leyden (as I've shared initially); Thus, I
>> am forwarding this to leyden-dev instead, so you can see what approach
>> Leyden uses to accomplish the same goal as yours.
>>
>> Regards, Chen Liang
>>
>> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>
>> <mailto:amansha at kth.se<mailto:amansha at kth.se> <mailto:amansha at kth.se>>> wrote:
>>
>>     __
>>
>>     Hi Roger,
>>
>>
>>     Do you have ideas on how to intercept them? My javaagent is not able
>>     to nor a JVMTI agent passed using `agentpath` option. It also does
>>     not seem to show up in logs when I pass `-verbose:class`.
>>
>>
>>     Also, what do you think of renaming the proxy classes as suggested
>>     below?
>>
>>
>>     Regards,
>>     Aman Sharma
>>
>>     PhD Student
>>     KTH Royal Institute of Technology
>>     School of Electrical Engineering and Computer Science (EECS)
>>     Department of Theoretical Computer Science (TCS)
>>     <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>>
>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>>     <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>     ------------------------------------------------------------------------
>>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>
>>     <mailto:core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>
> <mailto:core-libs-dev-retn at openjdk.org>>> on behalf of Roger Riggs
>>     <roger.riggs at oracle.com<mailto:roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com<mailto:roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com>>>
>>     *Sent:* Friday, May 17, 2024 4:57:46 AM
>>     *To:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org>>
>>     *Subject:* Re: Deterministic naming of subclasses of
>>     `java/lang/reflect/Proxy`
>>     Hi Aman,
>>
>>     You may also run into hidden classes (JEP 371: Hidden Classes) that
>>     allow classes to be defined, at runtime, without names.
>>     It has been proposed to use them for generated proxies but that
>>     hasn't been implemented yet.
>>     There are benefits to having nameless classes, because they can't be
>>     referenced by name, only as a capability, they can be better
>>     encapsulated.
>>
>>     fyi, Roger Riggs
>>
>>
>>     On 5/16/24 8:11 AM, Aman Sharma wrote:
>>>
>>>     Hi,
>>>
>>>
>>>     Thanks for your response, Liang!
>>>
>>>
>>>     > I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>
>>>     Sorry of the error. I indeed meant CVE-2021-42392
>>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392
> <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
>>>
>>>
>>>     > Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded
>>>
>>>
>>>     Would love to know the details of Project Leyden and how they
>>>     worked so far to focus on this goal. In our case, the training run
>>>     is the test suite.
>>>
>>>
>>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>>>     in Java 18
>>>
>>>
>>>     I did see them not appearing in my allowlist when I ran my study
>>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
>>>     about this JEP. I see they are re-implemented with method handles.
>>>
>>>
>>>     > How are you checking the classes?
>>>
>>>
>>>     To detect runtime generated code, we have javaagent that is hooked
>>>     statically to the test suite execution. It gives us all classes
>>>     that that is loaded post the JVM and the javaagent are loaded. So
>>>     we only check the classes loaded for the purpose of running the
>>>     application. This is also why we did not choose -agentlib as it
>>>     would give classes for the setting up JVM and javaagent and we the
>>>     user of our tool must the classes they load.
>>>
>>>
>>>     Next, we have a `ClassFileTransformer` hook in the agent where we
>>>     produce the checksum using the bytecode. And we compare the
>>>     checksum with the one existing in the allowlist. The checksum
>>>     computation algorithm is same for both steps. Let me describe how
>>>     I compute the checksum.
>>>
>>>
>>>      1. I get the CONSTANT_Class_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>> corresponding to a fix String constant, say "foo".
>>>      2. Since, the name of the class is used to refer to its types
>>>         members (fields/method), I get all CONSTANT_Fieldref_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
>>>      3. Next, since the naming of the fields, in Proxy classes, are
>>>         also suffixed by numbers, for example, `private static Method
>>>         m4`, we rewrite the UTF8 value of name in the
>>>         CONSTANT_NameAndType_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>>.
>>>      4. These fields can also have a random order so we simply sort
>>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
>>>         any differences due to ordering of fields/methods.
>>>      5. Simply sorting the byte array still had minute differences. I
>>>         could not understand why they existed even though values in
>>>         constant pool of the bytecode in allowlist and at runtime were
>>>         exactly the same after rewriting. The differences existed in
>>>         the bytes of the Code attribute of methods. I concluded that
>>>         the bytes stored some position information. To avoid this, I
>>>         created a subarray where I considered the bytes corresponding
>>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>>>         it resulted in the same checksums for both classfiles.
>>>
>>>
>>>     Let's understand the whole approach with an example of Proxy class.
>>>
>>>     `
>>>     public  final  class  $Proxy42  extends  Proxy  implements  org.apache.logging.log4j.core.config.plugins.Plugin  {
>>>     `
>>>
>>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>>>
>>>     When the same class is intercepted at runtime, say "$Proxy10", we
>>>     look for "Proxy_Plugin" in the allowlist and since the checksum
>>>     algorithm is same in both cases, we get a match and let the class
>>>     load.
>>>
>>>     This approach has seemed to work well for Proxy classes, Generated
>>>     Constructor Accessor (which is removed as you said). I also looked
>>>     at the species generated by method handles. I did not notice any
>>>     modification in them. Their name generation seemed okay to me. If
>>>     some new Species are generated, it is of course detected since it
>>>     is not in the allowlist.
>>>
>>>     I have not looked into LambdaMetafactory because I did not
>>>     encounter it as a problem so far, but I am aware its name
>>>     generation is also unstable. I have run my approach only a few
>>>     projects only. And for hidden classes, I assume the the agent
>>>     won't be able to intercept them so detecting them would be really
>>>     hard.
>>>
>>>
>>>     Regards,
>>>     Aman Sharma
>>>
>>>     PhD Student
>>>     KTH Royal Institute of Technology
>>>     School of Electrical Engineering and Computer Science (EECS)
>>>     Department of Theoretical Computer Science (TCS)
>>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>     ------------------------------------------------------------------------
>>>     *From:* liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>>
>>>     <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>> <mailto:liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>>
>>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
>>>     *To:* Aman Sharma; core-libs-dev
>>>     *Cc:* Martin Monperrus
>>>     *Subject:* Re: Deterministic naming of subclasses of
>>>     `java/lang/reflect/Proxy`
>>>     Hi Aman,
>>>     I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>     For your approach of an "allowlist" for Java runtime, project
>>>     Leyden is looking to generate a static image [1], that
>>>     > At run time it cannot load classes from outside the image, nor
>>>     can it create classes dynamically.
>>>     Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded and even object graphs; I
>>>     am not familiar with the details unfortunately.
>>>
>>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
>>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
>>>     replying this thread to core-libs-dev.
>>>
>>>     For your perceived problem that classes don't have unique names,
>>>     your description sounds dubious: GeneratedConstructorAccessor is
>>>     already retired by JEP 416 [2] in Java 18, and there are many
>>>     other cases in which JDK generates classes without stable names,
>>>     notoriously LambdaMetafactory (Gradle wished for cacheable
>>>     Lambdas); the same applies for the generated classes for
>>>     MethodHandle's LambdaForms (which carries implementation code for
>>>     LambdaForm). How are you checking the classes? It seems you are
>>>     not checking hidden classes. Proxy and Lambda classes are defined
>>>     by the caller's class loader, while LambdaForms are under JDK's
>>>     system class loader I think. We need to ensure you are correctly
>>>     finding all unstable classes before we can proceed.
>>>
>>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>
>>>     <https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>>
>>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
> <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
>>>
>>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>
>>>     <mailto:amansha at kth.se<mailto:amansha at kth.se> <mailto:amansha at kth.se>>> wrote:
>>>
>>>         Hi,
>>>
>>>
>>>         My name is Aman and I am a PhD student at KTH Royal Institute
>>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
>>>         <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>> project to
> strengthen the
>>>         software supply chain of multiple ecosystem. I particularly
>>>         focus on runtime integrity in Java. In this email, I want to
>>>         write about an issue I have discovered with /dynamic
>>>         generation of `java.lang.reflect.Proxy`classes/. I will
>>>         propose a solution and would love to hear the feedback from
>>>         the community. Let me know if this is the correct mailing-list
>>>         for such discussions. It seemed the most relevant from this
>>>         list <https://mail.openjdk.org/mailman/listinfo
> <https://mail.openjdk.org/mailman/listinfo>>.
>>>
>>>
>>>         *My research*
>>>
>>>         *
>>>         *
>>>
>>>         Java has features to load class on the fly - it can either
>>>         download or generate a class at runtime. These features are
>>>         useful for inner workings of JDK. For example, implementing
>>>         annotations, reflective access, etc. However, these features
>>>         have also contributed to critical vulnerabilities in the past
>>>         - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
>>>         All of these vulnerabilities have one thing in common - /a
>>>         class that was not known during build time was
>>>         downloaded/generated at runtime and loaded into JVM./
>>>
>>>
>>>         To defend against such vulnerabilities, we propose a solution
>>>         to /allowlist classes for runtime/. This allowlist will
>>>         contain an exhaustive list of classes that can be loaded by
>>>         the JVM and it will be enforced at runtime. We build this
>>>         allowlist from three sources:
>>>
>>>          1. All classes of all modules provided by the Java Standard
>>>             Library. We use ClassGraph
>>>             <https://github.com/classgraph/classgraph
> <https://github.com/classgraph/classgraph>> to scan the JDK.
>>>          2. We can take the source code and all dependencies of an
>>>             application. We use a software bill of materials to get
>>>             all the data.
>>>          3. Finally, we use run the test suite to include any runtime
>>>             downloaded/generated classes.
>>>
>>>         Such a list is able to prevent the above 3 CVEs because it
>>>         does not let the "unknown" bytecode to be loaded.
>>>
>>>         *Problem with generating such an allowlist*
>>>         *
>>>         *
>>>         The first two parts of the allowlist are easy to get. The
>>>         problem is with the third step where we want to allowlist all
>>>         the classes that could be downloaded or generated. Upon
>>>         running the test suite and hooking to the classes it loads, we
>>>         observer that the list consists of classes that are called
>>>         "com/sun/proxy/$Proxy2",
>>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>>>         many more. The purpose of these classes can be identifed. The
>>>         proxy class is created for to implement an annotation. The
>>>         accessor gives access to constructor of a class to the JVM.
>>>
>>>         When enforcing this allowlist at runtime, we see that the
>>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
>>>         allowlist and at runtime. In our case, we we are experimenting
>>>         with pdfbox <https://github.com/apache/pdfbox <https://github.com/apache/pdfbox>> so
> we created
>>>         the allowlist using its test suite. Then we enforced this
>>>         allowlist while running some of its subcommands. However,
>>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
>>>         at runtime that implemented the same interfaces and had the
>>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>>>         only differed in the name of the class, order of fields, and
>>>         types for fields references. This could happen because the
>>>         order of the loading of class is workload dependent, but it
>>>         causes problem to generate such an allowlist.
>>>
>>>         *Solution
>>>         *
>>>
>>>
>>>         We propose that naming of subclasses of
>>>         "java/lang/reflect/Proxy" should not be dependent upon the
>>>         order of loading. In order to do so, two issues can be fixed:
>>>
>>>          1. The naming of the class should not be based on AtomicLong
>>>             <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531 <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
>>>          2. Methods of the interfaces must be in a particular order.
>>>             Right now, they are not sorted in any particular order
>>>             <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178 <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>>.
>>>
>>>
>>>         These fixes will make proxy class generation deterministic
>>>         with respect to order of loading and won't be flagged at
>>>         runtime since the test suite would already detect them.
>>>
>>>         I would love to hear from the community about these ideas. If
>>>         in agreement, I would be happy to produce a patch. I have
>>>         discovered this issue with subclasses of
>>>         GeneratedConstructorAccessor
>>>         <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.
>>>
>>>         I also have PoCs for the above CVEs
>>>         <https://github.com/chains-project/exploits-for-sbom.exe
> <https://github.com/chains-project/exploits-for-sbom.exe>> and
>>>         a proof concept tool is being developed under the name
>>>         sbom.exe <https://github.com/chains-project/sbom.exe
> <https://github.com/chains-project/sbom.exe>> in case
>>>         any one wonders about the implementation. I would also be
>>>         happy to explain more.
>>>
>>>         Regards,
>>>         Aman Sharma
>>>
>>>         PhD Student
>>>         KTH Royal Institute of Technology
>>>         School of Electrical Engineering and Computer Science (EECS)
>>>         Department of Theoretical Computer Science (TCS)
>>>         <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240522/39a71b5c/attachment.htm>

From duke at openjdk.org  Wed May 22 18:49:17 2024
From: duke at openjdk.org (duke)
Date: Wed, 22 May 2024 18:49:17 GMT
Subject: git: openjdk/leyden: premain: Add snapshotting mechanism for training
 data
Message-ID: <7f0bc214-32fb-488c-b131-08988b083692@openjdk.org>

Changeset: 15f51139
Author:    Igor Veresov <igor.veresov at oracle.com>
Date:      2024-05-22 11:48:06 +0000
URL:       https://git.openjdk.org/leyden/commit/15f51139f2d534f3f7a9143e746acdd6efdb9f72

Add snapshotting mechanism for training data

! src/hotspot/share/oops/trainingData.cpp
! src/hotspot/share/oops/trainingData.hpp


From liangchenblue at gmail.com  Wed May 22 19:37:16 2024
From: liangchenblue at gmail.com (Chen Liang)
Date: Wed, 22 May 2024 14:37:16 -0500
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <eabfa5ae508e4257bd0c9bbef244637f@kth.se>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>
 <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
 <580b3aacd8df48fcaae3399718e229ab@kth.se>
 <CABe8uE065Q3+0yNjtyDF-eJM4LN-MbY9kfC44CnSQ-KM4p862g@mail.gmail.com>
 <b64077d6cf0045e98b630cf888785182@kth.se>
 <eabfa5ae508e4257bd0c9bbef244637f@kth.se>
Message-ID: <CABe8uE13qRX7pRXJOdhUF0sUwF5WkxTAM517tSTOi1r2Q7ivOg@mail.gmail.com>

Hi Aman,
Even though the specification says "not in any particular order," the
getInterfaces and getMethods actually return an ordered array, in the order
these methods/interfaces are declared in their class files.

I believe you are decompiling the proxy classes generated by an older
version of the JDK; for example, back in JDK 8, the proxy methods were not
ordered because they were tracked in a HashMap:
https://github.com/openjdk/jdk8u/blob/6b53212ef78ad50f9eede829c5ff87cadcdb434b/jdk/src/share/classes/sun/misc/ProxyGenerator.java#L405
Which is no longer the case:
https://github.com/openjdk/jdk/blob/d59c12fe1041a1f61f68408241a9aa4d96ac4fd2/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#L241

- Chen

On Wed, May 22, 2024 at 1:19?PM Aman Sharma <amansha at kth.se> wrote:

> Hi,
>
>
> Another thing I wanted to look into in this thread was the order of fields
> in the Proxy classes generated. They are also based on the a number. The
> same proxy classes across different executions can have random order of
> `Method` fields and the methods could be mapped to different field names.
>
>
> For example, consider the proxy class based on `picocli.CommandLine
> <https://github.com/remkop/picocli/blob/da98db63d1b516141b7485881b0dcddfd082dbc8/src/main/java/picocli/CommandLine.java#L4541>`
> in two different executions.
>
> // fields and method are truncated for brevity
> public final class $Proxy9 extends Proxy implements CommandLine.Command {
>     private static Method m1;
>     private static Method m32;
>     private static Method m21;
>     private static Method m43;
>     private static Method m36;
>     private static Method m27;
>
>     public final boolean helpCommand() throws  {
>         try {
>             return (Boolean)super.h.invoke(this, m32, (Object[])null);
>         } catch (RuntimeException | Error var2) {
>             throw var2;
>         } catch (Throwable var3) {
>             throw new UndeclaredThrowableException(var3);
>         }
>      }
>
> // fields and method are truncated for brevity
> public final class $Proxy13 extends Proxy implements CommandLine.Command {
>     private static Method m1;
>     private static Method m29;
>     private static Method m16;
>     private static Method m40;
>     private static Method m38;
>     private static Method m12;
>
>     public final boolean helpCommand() throws  {
>         try {
>             return (Boolean)super.h.invoke(this, m29, (Object[])null);
>         } catch (RuntimeException | Error var2) {
>             throw var2;
>         } catch (Throwable var3) {
>             throw new UndeclaredThrowableException(var3);
>         }
>     }
>
>
> Notice the difference in the order of fields and `helpCommand` method is
> mapped to a different field name in both classes. This happens because
> the method array returned by `getMethods` is not sorted in any particular
> order
> <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>
> when generating a proxy class. What dictates this order? And why is it
> not deterministic?
>
>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> ------------------------------
> *From:* Aman Sharma
> *Sent:* Wednesday, May 22, 2024 4:12:19 PM
> *To:* Chen Liang
> *Cc:* David Holmes; core-libs-dev at openjdk.org; leyden-dev at openjdk.org
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
>
>
> Hi Chen,
>
>
> That's clear. Thanks for letting me know. I guess then Project Leyden is
> working on naming the hidden classes deterministically to achieve their
> goals <https://openjdk.org/projects/leyden/notes/01-beginnings>.
>
>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> ------------------------------
> *From:* Chen Liang <liangchenblue at gmail.com>
> *Sent:* Wednesday, May 22, 2024 1:35:46 PM
> *To:* Aman Sharma
> *Cc:* David Holmes; core-libs-dev at openjdk.org; leyden-dev at openjdk.org
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
>
> Hi Aman,
> We have tried defining Proxy as hidden classes; a previous attempt was on
> hold because of issues with serialization. Otherwise, Proxies work great as
> hidden classes.
>
> Chen
>
> On Mon, May 20, 2024 at 7:56?AM Aman Sharma <amansha at kth.se> wrote:
>
>> Hi David,
>>
>>
>> > I would not expect any class load
>> events.
>>
>>
>> I understand. I also haven't tried to intercept them but I see only one
>> approach right now to include them in an allowlist - 1) statically look for
>> invocations of "Lookup::defineHiddenClass". 2) Instrument them so that
>> its first argument "bytes" can be looked into upon. I haven't looked into
>> it much because I did not have much idea about it. And they are hidden so
>> it made it worse. ? Thanks for sharing the JEP!
>>
>>
>> >
>> java.lang.reflect.Proxy could define hidden classes to act as the proxy
>> classes which implement proxy interfaces; from JEP 317
>>
>>
>> It says that Proxy classes will also become hidden classes. Is it
>> underway? Right now one can intercept, transform them, and include them in
>> an allowlist. What do you think of naming them independent of AtomicLong so
>> that a proxy class generated at runtime is easy to lookup in the allowlist?
>>
>>
>>
>> Regards,
>> Aman Sharma
>>
>> PhD Student
>> KTH Royal Institute of Technology
>> School of Electrical Engineering and Computer Science (EECS)
>> Department of Theoretical Computer Science (TCS)
>> <http://www.kth.se> <https://www.kth.se/profile/amansha>
>> <https://www.kth.se/profile/amansha>
>> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
>> ------------------------------
>> *From:* David Holmes <david.holmes at oracle.com>
>> *Sent:* Monday, May 20, 2024 2:30:37 PM
>> *To:* Aman Sharma; liangchenblue at gmail.com
>> *Cc:* core-libs-dev at openjdk.org; leyden-dev at openjdk.org
>> *Subject:* Re: Deterministic naming of subclasses of
>> `java/lang/reflect/Proxy`
>>
>> On 20/05/2024 10:12 pm, Aman Sharma wrote:
>> > Hi David,
>> >
>> >
>> >  > How did you try to intercept them? Hidden classes are not "loaded" in
>> > the normal sense so won't trigger class load events.
>> >
>> >
>> > I could not intercept them. I only see them when I pass
>> `-verbose:class`
>> > in the Java CLI.
>>
>> Yes that is why I asked how you tried to intercept them.
>>
>> >
>> > I also couldn't intercept them using JVMTI Class File Load Hook
>> > <
>> https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook>
>> event. However JEP 371 suggests that it should be possible to intercept
>> them using JVMTI Class Load <
>> https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad>
>> event, but I won't have the bytecode at this stage. So is there no way to
>> get its bytecode before it is linked and initialized in the JVM?
>>
>> Hidden classes are not loaded so I would not expect any class load
>> events. However the exact nature of the JVMTI class load event is
>> unclear as it talks about "class or interface creation" which is neither
>> loading or defining per se. But a class prepare event sounds like it
>> should be issued. However neither give you access to the bytecode of the
>> class AFAICS.
>>
>> David
>> -----
>>
>>
>> >
>> > Regards,
>> > Aman Sharma
>> >
>> > PhD Student
>> > KTH Royal Institute of Technology
>> > School of Electrical Engineering and Computer Science (EECS)
>> > Department of Theoretical Computer Science (TCS)
>> > <
>> http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha
>> >
>> > <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
>> > <https://algomaster99.github.io/>
>> > ------------------------------------------------------------------------
>> > *From:* David Holmes <david.holmes at oracle.com>
>> > *Sent:* Monday, May 20, 2024 2:59:17 AM
>> > *To:* Aman Sharma; liangchenblue at gmail.com
>> > *Cc:* core-libs-dev at openjdk.org; leyden-dev at openjdk.org
>> > *Subject:* Re: Deterministic naming of subclasses of
>> > `java/lang/reflect/Proxy`
>> > On 17/05/2024 9:43 pm, Aman Sharma wrote:
>> >> Hi Chen,
>> >>
>> >>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
>> >>
>> >> I do see this as output when I pass -verbose:class. However, based on
>> my
>> >> experiments, I have seen that neither an agent passed via 'javaagent'
>> >> nor an agent passed via 'agentpath' is able to intercept this hidden
>> class.
>> >
>> > How did you try to intercept them? Hidden classes are not "loaded" in
>> > the normal sense so won't trigger class load events.
>> >
>> >> Also, I was a bit confused since I saw somewhere that the names of
>> >> hidden classes are null. But thanks for clarifying here.
>> >
>> > The JEP clearly defines the name format for hidden classes - though the
>> > final component is VM specific (and typically a hashcode).
>> >
>> > https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
>> >
>> > Cheers,
>> > David
>> > -----
>> >
>> >>  > avoid dynamic class loading
>> >>
>> >> I don't see dynamic class loading as a problem. I only mind some
>> >> unstable generation aspects of them which make it hard to verify them
>> >> based on an allowlist.
>> >>
>> >> For example, if this hidden class is generated with the exact same
>> name
>> >> and the exact same bytecode during runtime as well, it would be easy
>> to
>> >> verify it. However, I do see the names are based on some sort of
>> memory
>> >> address so and I don't know what bytecode it has so I don't have
>> >> suggestions to make them stable as of now. For Proxy classes, I feel
>> it
>> >> can be addressed unless you disagree or some involved in Project
>> Leyden
>> >> does. :) Thank you for forwarding my mail there.
>> >>
>> >> Regards,
>> >> Aman Sharma
>> >>
>> >> PhD Student
>> >> KTH Royal Institute of Technology
>> >> https://algomaster99.github.io/ <https://algomaster99.github.io/>
>> > <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>> >>
>> >>
>> ------------------------------------------------------------------------
>> >> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
>> >> *Sent:* Friday, May 17, 2024 1:23:58 pm
>> >> *To:* Aman Sharma <amansha at kth.se>
>> >> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>;
>> >> leyden-dev at openjdk.org <leyden-dev at openjdk.org>
>> >> *Subject:* Re: Deterministic naming of subclasses of
>> >> `java/lang/reflect/Proxy`
>> >>
>> >> Hi Aman,
>> >> For `-verbose:class`, it's a JVM argument instead of a program
>> argument;
>> >> so when you run a java program like `java Main`, you should call it as
>> >> `java -verbose:class Main`.
>> >> When done correctly, you should see hidden class outputs like:
>> >> [0.032s][info][class,load]
>> >> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
>> >> __JVM_LookupDefineClass__
>> >> The loading of java.lang.invoke hidden classes requires your program
>> to
>> >> use MethodHandle features, like a lambda.
>> >>
>> >> I think the problem you are exploring, that to avoid dynamic class
>> >> loading and effectively turn Java Platform closed for security, is
>> also
>> >> being accomplished by project Leyden (as I've shared initially); Thus,
>> I
>> >> am forwarding this to leyden-dev instead, so you can see what approach
>> >> Leyden uses to accomplish the same goal as yours.
>> >>
>> >> Regards, Chen Liang
>> >>
>> >> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se
>> >> <mailto:amansha at kth.se <mailto:amansha at kth.se <amansha at kth.se>>>>
>> wrote:
>> >>
>> >>     __
>> >>
>> >>     Hi Roger,
>> >>
>> >>
>> >>     Do you have ideas on how to intercept them? My javaagent is not
>> able
>> >>     to nor a JVMTI agent passed using `agentpath` option. It also does
>> >>     not seem to show up in logs when I pass `-verbose:class`.
>> >>
>> >>
>> >>     Also, what do you think of renaming the proxy classes as suggested
>> >>     below?
>> >>
>> >>
>> >>     Regards,
>> >>     Aman Sharma
>> >>
>> >>     PhD Student
>> >>     KTH Royal Institute of Technology
>> >>     School of Electrical Engineering and Computer Science (EECS)
>> >>     Department of Theoretical Computer Science (TCS)
>> >>     <http://www.kth.se><https://www.kth.se/profile/amansha><
>> https://www.kth.se/profile/amansha <
>> http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha
>> >>
>> >>     <https://www.kth.se/profile/amansha
>> > <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>> >>     <https://algomaster99.github.io/ <https://algomaster99.github.io/
>> >>
>> >>
>> ------------------------------------------------------------------------
>> >>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org
>> >>     <mailto:core-libs-dev-retn at openjdk.org
>> > <mailto:core-libs-dev-retn at openjdk.org <core-libs-dev-retn at openjdk.org>>>>
>> on behalf of Roger Riggs
>> >>     <roger.riggs at oracle.com <mailto:roger.riggs at oracle.com <
>> mailto:roger.riggs at oracle.com <roger.riggs at oracle.com>>>>
>> >>     *Sent:* Friday, May 17, 2024 4:57:46 AM
>> >>     *To:* core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org
>> <mailto:core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>>>
>> >>     *Subject:* Re: Deterministic naming of subclasses of
>> >>     `java/lang/reflect/Proxy`
>> >>     Hi Aman,
>> >>
>> >>     You may also run into hidden classes (JEP 371: Hidden Classes) that
>> >>     allow classes to be defined, at runtime, without names.
>> >>     It has been proposed to use them for generated proxies but that
>> >>     hasn't been implemented yet.
>> >>     There are benefits to having nameless classes, because they can't
>> be
>> >>     referenced by name, only as a capability, they can be better
>> >>     encapsulated.
>> >>
>> >>     fyi, Roger Riggs
>> >>
>> >>
>> >>     On 5/16/24 8:11 AM, Aman Sharma wrote:
>> >>>
>> >>>     Hi,
>> >>>
>> >>>
>> >>>     Thanks for your response, Liang!
>> >>>
>> >>>
>> >>>     > I think you meant CVE-2021-42392 instead of 2022.
>> >>>
>> >>>
>> >>>     Sorry of the error. I indeed meant CVE-2021-42392
>> >>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392
>> > <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
>> >>>
>> >>>
>> >>>     > Leyden mainly avoids this unstable generation by performing a
>> >>>     training run to collect classes loaded
>> >>>
>> >>>
>> >>>     Would love to know the details of Project Leyden and how they
>> >>>     worked so far to focus on this goal. In our case, the training run
>> >>>     is the test suite.
>> >>>
>> >>>
>> >>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>> >>>     in Java 18
>> >>>
>> >>>
>> >>>     I did see them not appearing in my allowlist when I ran my study
>> >>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
>> >>>     about this JEP. I see they are re-implemented with method handles.
>> >>>
>> >>>
>> >>>     > How are you checking the classes?
>> >>>
>> >>>
>> >>>     To detect runtime generated code, we have javaagent that is hooked
>> >>>     statically to the test suite execution. It gives us all classes
>> >>>     that that is loaded post the JVM and the javaagent are loaded. So
>> >>>     we only check the classes loaded for the purpose of running the
>> >>>     application. This is also why we did not choose -agentlib as it
>> >>>     would give classes for the setting up JVM and javaagent and we the
>> >>>     user of our tool must the classes they load.
>> >>>
>> >>>
>> >>>     Next, we have a `ClassFileTransformer` hook in the agent where we
>> >>>     produce the checksum using the bytecode. And we compare the
>> >>>     checksum with the one existing in the allowlist. The checksum
>> >>>     computation algorithm is same for both steps. Let me describe how
>> >>>     I compute the checksum.
>> >>>
>> >>>
>> >>>      1. I get the CONSTANT_Class_info
>> >>>         <
>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1
>> <
>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>>
>> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <
>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7
>> <
>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>>
>> corresponding to a fix String constant, say "foo".
>> >>>      2. Since, the name of the class is used to refer to its types
>> >>>         members (fields/method), I get all CONSTANT_Fieldref_info
>> >>>         <
>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2
>> <
>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>>
>> and if its `class_index` corresponds to the old `this_class`, we rewrite
>> the UTF8 value of class_index to the same constant "foo".
>> >>>      3. Next, since the naming of the fields, in Proxy classes, are
>> >>>         also suffixed by numbers, for example, `private static Method
>> >>>         m4`, we rewrite the UTF8 value of name in the
>> >>>         CONSTANT_NameAndType_info
>> >>>         <
>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6
>> <
>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6
>> >>.
>> >>>      4. These fields can also have a random order so we simply sort
>> >>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
>> >>>         any differences due to ordering of fields/methods.
>> >>>      5. Simply sorting the byte array still had minute differences. I
>> >>>         could not understand why they existed even though values in
>> >>>         constant pool of the bytecode in allowlist and at runtime were
>> >>>         exactly the same after rewriting. The differences existed in
>> >>>         the bytes of the Code attribute of methods. I concluded that
>> >>>         the bytes stored some position information. To avoid this, I
>> >>>         created a subarray where I considered the bytes corresponding
>> >>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>> >>>         it resulted in the same checksums for both classfiles.
>> >>>
>> >>>
>> >>>     Let's understand the whole approach with an example of Proxy
>> class.
>> >>>
>> >>>     `
>> >>>     public  final  class  $Proxy42  extends  Proxy  implements
>> org.apache.logging.log4j.core.config.plugins.Plugin  {
>> >>>     `
>> >>>
>> >>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>> >>>
>> >>>     When the same class is intercepted at runtime, say "$Proxy10", we
>> >>>     look for "Proxy_Plugin" in the allowlist and since the checksum
>> >>>     algorithm is same in both cases, we get a match and let the class
>> >>>     load.
>> >>>
>> >>>     This approach has seemed to work well for Proxy classes, Generated
>> >>>     Constructor Accessor (which is removed as you said). I also looked
>> >>>     at the species generated by method handles. I did not notice any
>> >>>     modification in them. Their name generation seemed okay to me. If
>> >>>     some new Species are generated, it is of course detected since it
>> >>>     is not in the allowlist.
>> >>>
>> >>>     I have not looked into LambdaMetafactory because I did not
>> >>>     encounter it as a problem so far, but I am aware its name
>> >>>     generation is also unstable. I have run my approach only a few
>> >>>     projects only. And for hidden classes, I assume the the agent
>> >>>     won't be able to intercept them so detecting them would be really
>> >>>     hard.
>> >>>
>> >>>
>> >>>     Regards,
>> >>>     Aman Sharma
>> >>>
>> >>>     PhD Student
>> >>>     KTH Royal Institute of Technology
>> >>>     School of Electrical Engineering and Computer Science (EECS)
>> >>>     Department of Theoretical Computer Science (TCS)
>> >>>     <https://www.kth.se/profile/amansha
>> > <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>> > <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>> >>>
>> ------------------------------------------------------------------------
>> >>>     *From:* liangchenblue at gmail.com <mailto:liangchenblue at gmail.com <
>> mailto:liangchenblue at gmail.com <liangchenblue at gmail.com>>>
>> >>>     <liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com <
>> mailto:liangchenblue at gmail.com <liangchenblue at gmail.com>>>
>> >>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
>> >>>     *To:* Aman Sharma; core-libs-dev
>> >>>     *Cc:* Martin Monperrus
>> >>>     *Subject:* Re: Deterministic naming of subclasses of
>> >>>     `java/lang/reflect/Proxy`
>> >>>     Hi Aman,
>> >>>     I think you meant CVE-2021-42392 instead of 2022.
>> >>>
>> >>>     For your approach of an "allowlist" for Java runtime, project
>> >>>     Leyden is looking to generate a static image [1], that
>> >>>     > At run time it cannot load classes from outside the image, nor
>> >>>     can it create classes dynamically.
>> >>>     Leyden mainly avoids this unstable generation by performing a
>> >>>     training run to collect classes loaded and even object graphs; I
>> >>>     am not familiar with the details unfortunately.
>> >>>
>> >>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
>> >>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
>> >>>     replying this thread to core-libs-dev.
>> >>>
>> >>>     For your perceived problem that classes don't have unique names,
>> >>>     your description sounds dubious: GeneratedConstructorAccessor is
>> >>>     already retired by JEP 416 [2] in Java 18, and there are many
>> >>>     other cases in which JDK generates classes without stable names,
>> >>>     notoriously LambdaMetafactory (Gradle wished for cacheable
>> >>>     Lambdas); the same applies for the generated classes for
>> >>>     MethodHandle's LambdaForms (which carries implementation code for
>> >>>     LambdaForm). How are you checking the classes? It seems you are
>> >>>     not checking hidden classes. Proxy and Lambda classes are defined
>> >>>     by the caller's class loader, while LambdaForms are under JDK's
>> >>>     system class loader I think. We need to ensure you are correctly
>> >>>     finding all unstable classes before we can proceed.
>> >>>
>> >>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
>> > <https://openjdk.org/projects/leyden/notes/01-beginnings>
>> >>>     <https://openjdk.org/projects/leyden/notes/01-beginnings
>> > <https://openjdk.org/projects/leyden/notes/01-beginnings>>
>> >>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
>> > <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
>> >>>
>> >>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se
>> >>>     <mailto:amansha at kth.se <mailto:amansha at kth.se <amansha at kth.se>>>>
>> wrote:
>> >>>
>> >>>         Hi,
>> >>>
>> >>>
>> >>>         My name is Aman and I am a PhD student at KTH Royal Institute
>> >>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
>> >>>         <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>>
>> project to
>> > strengthen the
>> >>>         software supply chain of multiple ecosystem. I particularly
>> >>>         focus on runtime integrity in Java. In this email, I want to
>> >>>         write about an issue I have discovered with /dynamic
>> >>>         generation of `java.lang.reflect.Proxy`classes/. I will
>> >>>         propose a solution and would love to hear the feedback from
>> >>>         the community. Let me know if this is the correct mailing-list
>> >>>         for such discussions. It seemed the most relevant from this
>> >>>         list <https://mail.openjdk.org/mailman/listinfo
>> > <https://mail.openjdk.org/mailman/listinfo>>.
>> >>>
>> >>>
>> >>>         *My research*
>> >>>
>> >>>         *
>> >>>         *
>> >>>
>> >>>         Java has features to load class on the fly - it can either
>> >>>         download or generate a class at runtime. These features are
>> >>>         useful for inner workings of JDK. For example, implementing
>> >>>         annotations, reflective access, etc. However, these features
>> >>>         have also contributed to critical vulnerabilities in the past
>> >>>         - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
>> >>>         All of these vulnerabilities have one thing in common - /a
>> >>>         class that was not known during build time was
>> >>>         downloaded/generated at runtime and loaded into JVM./
>> >>>
>> >>>
>> >>>         To defend against such vulnerabilities, we propose a solution
>> >>>         to /allowlist classes for runtime/. This allowlist will
>> >>>         contain an exhaustive list of classes that can be loaded by
>> >>>         the JVM and it will be enforced at runtime. We build this
>> >>>         allowlist from three sources:
>> >>>
>> >>>          1. All classes of all modules provided by the Java Standard
>> >>>             Library. We use ClassGraph
>> >>>             <https://github.com/classgraph/classgraph
>> > <https://github.com/classgraph/classgraph>> to scan the JDK.
>> >>>          2. We can take the source code and all dependencies of an
>> >>>             application. We use a software bill of materials to get
>> >>>             all the data.
>> >>>          3. Finally, we use run the test suite to include any runtime
>> >>>             downloaded/generated classes.
>> >>>
>> >>>         Such a list is able to prevent the above 3 CVEs because it
>> >>>         does not let the "unknown" bytecode to be loaded.
>> >>>
>> >>>         *Problem with generating such an allowlist*
>> >>>         *
>> >>>         *
>> >>>         The first two parts of the allowlist are easy to get. The
>> >>>         problem is with the third step where we want to allowlist all
>> >>>         the classes that could be downloaded or generated. Upon
>> >>>         running the test suite and hooking to the classes it loads, we
>> >>>         observer that the list consists of classes that are called
>> >>>         "com/sun/proxy/$Proxy2",
>> >>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>> >>>         many more. The purpose of these classes can be identifed. The
>> >>>         proxy class is created for to implement an annotation. The
>> >>>         accessor gives access to constructor of a class to the JVM.
>> >>>
>> >>>         When enforcing this allowlist at runtime, we see that the
>> >>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
>> >>>         allowlist and at runtime. In our case, we we are experimenting
>> >>>         with pdfbox <https://github.com/apache/pdfbox <
>> https://github.com/apache/pdfbox>> so
>> > we created
>> >>>         the allowlist using its test suite. Then we enforced this
>> >>>         allowlist while running some of its subcommands. However,
>> >>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
>> >>>         at runtime that implemented the same interfaces and had the
>> >>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>> >>>         only differed in the name of the class, order of fields, and
>> >>>         types for fields references. This could happen because the
>> >>>         order of the loading of class is workload dependent, but it
>> >>>         causes problem to generate such an allowlist.
>> >>>
>> >>>         *Solution
>> >>>         *
>> >>>
>> >>>
>> >>>         We propose that naming of subclasses of
>> >>>         "java/lang/reflect/Proxy" should not be dependent upon the
>> >>>         order of loading. In order to do so, two issues can be fixed:
>> >>>
>> >>>          1. The naming of the class should not be based on AtomicLong
>> >>>             <
>> https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531
>> <
>> https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>>.
>> Rather it could be named based on the interfaces it implements. I also
>> wonder why AtomicLong is chosen in the first place.
>> >>>          2. Methods of the interfaces must be in a particular order.
>> >>>             Right now, they are not sorted in any particular order
>> >>>             <
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178
>> <
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178
>> >>.
>> >>>
>> >>>
>> >>>         These fixes will make proxy class generation deterministic
>> >>>         with respect to order of loading and won't be flagged at
>> >>>         runtime since the test suite would already detect them.
>> >>>
>> >>>         I would love to hear from the community about these ideas. If
>> >>>         in agreement, I would be happy to produce a patch. I have
>> >>>         discovered this issue with subclasses of
>> >>>         GeneratedConstructorAccessor
>> >>>         <
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java
>> <
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>>
>> as well and I imagine it will also apply to some other runtime generated
>> classes. If you disagree, please let me know also. It helps with my
>> research.
>> >>>
>> >>>         I also have PoCs for the above CVEs
>> >>>         <https://github.com/chains-project/exploits-for-sbom.exe
>> > <https://github.com/chains-project/exploits-for-sbom.exe>> and
>> >>>         a proof concept tool is being developed under the name
>> >>>         sbom.exe <https://github.com/chains-project/sbom.exe
>> > <https://github.com/chains-project/sbom.exe>> in case
>> >>>         any one wonders about the implementation. I would also be
>> >>>         happy to explain more.
>> >>>
>> >>>         Regards,
>> >>>         Aman Sharma
>> >>>
>> >>>         PhD Student
>> >>>         KTH Royal Institute of Technology
>> >>>         School of Electrical Engineering and Computer Science (EECS)
>> >>>         Department of Theoretical Computer Science (TCS)
>> >>>         <https://www.kth.se/profile/amansha
>> > <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>> > <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>> >>>
>> >>
>> >>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240522/cde58d87/attachment.htm>

From duke at openjdk.org  Thu May 23 03:53:29 2024
From: duke at openjdk.org (duke)
Date: Thu, 23 May 2024 03:53:29 GMT
Subject: git: openjdk/leyden: premain: Moved Leyden overview docs to
 $REPO/README.md
Message-ID: <5c36d519-c92d-4cfc-b652-15702d7ffb70@openjdk.org>

Changeset: 8dee825a
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-05-22 20:52:11 +0000
URL:       https://git.openjdk.org/leyden/commit/8dee825af45ee8fd0766117127b7f9ee5b61dbe7

Moved Leyden overview docs to $REPO/README.md

! README.md
! test/hotspot/jtreg/premain/README.md


From duke at openjdk.org  Thu May 23 20:58:38 2024
From: duke at openjdk.org (duke)
Date: Thu, 23 May 2024 20:58:38 GMT
Subject: git: openjdk/leyden: premain: Fixed typo and added disclaimers
Message-ID: <3b20a54e-381f-4cdd-b9b7-914a12eb48e9@openjdk.org>

Changeset: 32811147
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-05-23 13:56:57 +0000
URL:       https://git.openjdk.org/leyden/commit/3281114791cdd8198fe224b846d0d68b42aa817e

Fixed typo and added disclaimers

! README.md


From amansha at kth.se  Sat May 25 21:03:43 2024
From: amansha at kth.se (Aman Sharma)
Date: Sat, 25 May 2024 21:03:43 +0000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <CABe8uE13qRX7pRXJOdhUF0sUwF5WkxTAM517tSTOi1r2Q7ivOg@mail.gmail.com>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>
 <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
 <580b3aacd8df48fcaae3399718e229ab@kth.se>
 <CABe8uE065Q3+0yNjtyDF-eJM4LN-MbY9kfC44CnSQ-KM4p862g@mail.gmail.com>
 <b64077d6cf0045e98b630cf888785182@kth.se>
 <eabfa5ae508e4257bd0c9bbef244637f@kth.se>,
 <CABe8uE13qRX7pRXJOdhUF0sUwF5WkxTAM517tSTOi1r2Q7ivOg@mail.gmail.com>
Message-ID: <fb6a2cb13c2449acac32fdfb781b0ce0@kth.se>

Hi Chen,

I am attaching proxy classes generated in the JVM of OpenJDK 22. I, instead of decompiling, I disassembled them and I do see a difference. For example, see method `footerHeading` in both classes. In $Proxy9, it is mapped to `m39` field and in $Proxy13, it is mapped to `m21` field. What is the reason for this ordering? Why is mapping of methods to fields depend upon the execution?


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Chen Liang <liangchenblue at gmail.com>
Sent: Wednesday, May 22, 2024 9:37:16 PM
To: Aman Sharma
Cc: core-libs-dev at openjdk.org; leyden-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,
Even though the specification says "not in any particular order," the getInterfaces and getMethods actually return an ordered array, in the order these methods/interfaces are declared in their class files.

I believe you are decompiling the proxy classes generated by an older version of the JDK; for example, back in JDK 8, the proxy methods were not ordered because they were tracked in a HashMap: https://github.com/openjdk/jdk8u/blob/6b53212ef78ad50f9eede829c5ff87cadcdb434b/jdk/src/share/classes/sun/misc/ProxyGenerator.java#L405
Which is no longer the case: https://github.com/openjdk/jdk/blob/d59c12fe1041a1f61f68408241a9aa4d96ac4fd2/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#L241

- Chen

On Wed, May 22, 2024 at 1:19?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi,


Another thing I wanted to look into in this thread was the order of fields in the Proxy classes generated. They are also based on the a number. The same proxy classes across different executions can have random order of `Method` fields and the methods could be mapped to different field names.


For example, consider the proxy class based on `picocli.CommandLine<https://github.com/remkop/picocli/blob/da98db63d1b516141b7485881b0dcddfd082dbc8/src/main/java/picocli/CommandLine.java#L4541>` in two different executions.

// fields and method are truncated for brevity
public final class $Proxy9 extends Proxy implements CommandLine.Command {
    private static Method m1;
    private static Method m32;
    private static Method m21;
    private static Method m43;
    private static Method m36;
    private static Method m27;

    public final boolean helpCommand() throws  {
        try {
            return (Boolean)super.h.invoke(this, m32, (Object[])null);
        } catch (RuntimeException | Error var2) {
            throw var2;
        } catch (Throwable var3) {
            throw new UndeclaredThrowableException(var3);
        }
     }

// fields and method are truncated for brevity
public final class $Proxy13 extends Proxy implements CommandLine.Command {
    private static Method m1;
    private static Method m29;
    private static Method m16;
    private static Method m40;
    private static Method m38;
    private static Method m12;

    public final boolean helpCommand() throws  {
        try {
            return (Boolean)super.h.invoke(this, m29, (Object[])null);
        } catch (RuntimeException | Error var2) {
            throw var2;
        } catch (Throwable var3) {
            throw new UndeclaredThrowableException(var3);
        }
    }


Notice the difference in the order of fields and `helpCommand` method is mapped to a different field name in both classes. This happens because the method array returned by `getMethods` is not sorted in any particular order<https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178> when generating a proxy class. What dictates this order? And why is it not deterministic?


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Aman Sharma
Sent: Wednesday, May 22, 2024 4:12:19 PM
To: Chen Liang
Cc: David Holmes; core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`


Hi Chen,


That's clear. Thanks for letting me know. I guess then Project Leyden is working on naming the hidden classes deterministically to achieve their goals<https://openjdk.org/projects/leyden/notes/01-beginnings>.


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Chen Liang <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
Sent: Wednesday, May 22, 2024 1:35:46 PM
To: Aman Sharma
Cc: David Holmes; core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,
We have tried defining Proxy as hidden classes; a previous attempt was on hold because of issues with serialization. Otherwise, Proxies work great as hidden classes.

Chen

On Mon, May 20, 2024 at 7:56?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi David,


> I would not expect any class load
events.


I understand. I also haven't tried to intercept them but I see only one approach right now to include them in an allowlist - 1) statically look for invocations of "Lookup::defineHiddenClass". 2) Instrument them so that its first argument "bytes" can be looked into upon. I haven't looked into it much because I did not have much idea about it. And they are hidden so it made it worse. ? Thanks for sharing the JEP!


>

java.lang.reflect.Proxy could define hidden classes to act as the proxy classes which implement proxy interfaces; from JEP 317


It says that Proxy classes will also become hidden classes. Is it underway? Right now one can intercept, transform them, and include them in an allowlist. What do you think of naming them independent of AtomicLong so that a proxy class generated at runtime is easy to lookup in the allowlist?



Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
Sent: Monday, May 20, 2024 2:30:37 PM
To: Aman Sharma; liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

On 20/05/2024 10:12 pm, Aman Sharma wrote:
> Hi David,
>
>
>  > How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>
> I could not intercept them. I only see them when I pass `-verbose:class`
> in the Java CLI.

Yes that is why I asked how you tried to intercept them.

>
> I also couldn't intercept them using JVMTI Class File Load Hook
> <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook> event. However JEP 371 suggests that it should be possible to intercept them using JVMTI Class Load <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad> event, but I won't have the bytecode at this stage. So is there no way to get its bytecode before it is linked and initialized in the JVM?

Hidden classes are not loaded so I would not expect any class load
events. However the exact nature of the JVMTI class load event is
unclear as it talks about "class or interface creation" which is neither
loading or defining per se. But a class prepare event sounds like it
should be issued. However neither give you access to the bytecode of the
class AFAICS.

David
-----


>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> <https://algomaster99.github.io/>
> ------------------------------------------------------------------------
> *From:* David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
> *Sent:* Monday, May 20, 2024 2:59:17 AM
> *To:* Aman Sharma; liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>
> *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
> On 17/05/2024 9:43 pm, Aman Sharma wrote:
>> Hi Chen,
>>
>>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
>>
>> I do see this as output when I pass -verbose:class. However, based on my
>> experiments, I have seen that neither an agent passed via 'javaagent'
>> nor an agent passed via 'agentpath' is able to intercept this hidden class.
>
> How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>> Also, I was a bit confused since I saw somewhere that the names of
>> hidden classes are null. But thanks for clarifying here.
>
> The JEP clearly defines the name format for hidden classes - though the
> final component is VM specific (and typically a hashcode).
>
> https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
>
> Cheers,
> David
> -----
>
>>  > avoid dynamic class loading
>>
>> I don't see dynamic class loading as a problem. I only mind some
>> unstable generation aspects of them which make it hard to verify them
>> based on an allowlist.
>>
>> For example, if this hidden class is generated with the exact same name
>> and the exact same bytecode during runtime as well, it would be easy to
>> verify it. However, I do see the names are based on some sort of memory
>> address so and I don't know what bytecode it has so I don't have
>> suggestions to make them stable as of now. For Proxy classes, I feel it
>> can be addressed unless you disagree or some involved in Project Leyden
>> does. :) Thank you for forwarding my mail there.
>>
>> Regards,
>> Aman Sharma
>>
>> PhD Student
>> KTH Royal Institute of Technology
>> https://algomaster99.github.io/ <https://algomaster99.github.io/>
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>
>> ------------------------------------------------------------------------
>> *From:* liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
>> *Sent:* Friday, May 17, 2024 1:23:58 pm
>> *To:* Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>>
>> *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>;
>> leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org> <leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>>
>> *Subject:* Re: Deterministic naming of subclasses of
>> `java/lang/reflect/Proxy`
>>
>> Hi Aman,
>> For `-verbose:class`, it's a JVM argument instead of a program argument;
>> so when you run a java program like `java Main`, you should call it as
>> `java -verbose:class Main`.
>> When done correctly, you should see hidden class outputs like:
>> [0.032s][info][class,load]
>> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
>> __JVM_LookupDefineClass__
>> The loading of java.lang.invoke hidden classes requires your program to
>> use MethodHandle features, like a lambda.
>>
>> I think the problem you are exploring, that to avoid dynamic class
>> loading and effectively turn Java Platform closed for security, is also
>> being accomplished by project Leyden (as I've shared initially); Thus, I
>> am forwarding this to leyden-dev instead, so you can see what approach
>> Leyden uses to accomplish the same goal as yours.
>>
>> Regards, Chen Liang
>>
>> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>
>> <mailto:amansha at kth.se<mailto:amansha at kth.se> <mailto:amansha at kth.se>>> wrote:
>>
>>     __
>>
>>     Hi Roger,
>>
>>
>>     Do you have ideas on how to intercept them? My javaagent is not able
>>     to nor a JVMTI agent passed using `agentpath` option. It also does
>>     not seem to show up in logs when I pass `-verbose:class`.
>>
>>
>>     Also, what do you think of renaming the proxy classes as suggested
>>     below?
>>
>>
>>     Regards,
>>     Aman Sharma
>>
>>     PhD Student
>>     KTH Royal Institute of Technology
>>     School of Electrical Engineering and Computer Science (EECS)
>>     Department of Theoretical Computer Science (TCS)
>>     <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>>
>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>>     <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>     ------------------------------------------------------------------------
>>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>
>>     <mailto:core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>
> <mailto:core-libs-dev-retn at openjdk.org>>> on behalf of Roger Riggs
>>     <roger.riggs at oracle.com<mailto:roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com<mailto:roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com>>>
>>     *Sent:* Friday, May 17, 2024 4:57:46 AM
>>     *To:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org>>
>>     *Subject:* Re: Deterministic naming of subclasses of
>>     `java/lang/reflect/Proxy`
>>     Hi Aman,
>>
>>     You may also run into hidden classes (JEP 371: Hidden Classes) that
>>     allow classes to be defined, at runtime, without names.
>>     It has been proposed to use them for generated proxies but that
>>     hasn't been implemented yet.
>>     There are benefits to having nameless classes, because they can't be
>>     referenced by name, only as a capability, they can be better
>>     encapsulated.
>>
>>     fyi, Roger Riggs
>>
>>
>>     On 5/16/24 8:11 AM, Aman Sharma wrote:
>>>
>>>     Hi,
>>>
>>>
>>>     Thanks for your response, Liang!
>>>
>>>
>>>     > I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>
>>>     Sorry of the error. I indeed meant CVE-2021-42392
>>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392
> <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
>>>
>>>
>>>     > Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded
>>>
>>>
>>>     Would love to know the details of Project Leyden and how they
>>>     worked so far to focus on this goal. In our case, the training run
>>>     is the test suite.
>>>
>>>
>>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>>>     in Java 18
>>>
>>>
>>>     I did see them not appearing in my allowlist when I ran my study
>>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
>>>     about this JEP. I see they are re-implemented with method handles.
>>>
>>>
>>>     > How are you checking the classes?
>>>
>>>
>>>     To detect runtime generated code, we have javaagent that is hooked
>>>     statically to the test suite execution. It gives us all classes
>>>     that that is loaded post the JVM and the javaagent are loaded. So
>>>     we only check the classes loaded for the purpose of running the
>>>     application. This is also why we did not choose -agentlib as it
>>>     would give classes for the setting up JVM and javaagent and we the
>>>     user of our tool must the classes they load.
>>>
>>>
>>>     Next, we have a `ClassFileTransformer` hook in the agent where we
>>>     produce the checksum using the bytecode. And we compare the
>>>     checksum with the one existing in the allowlist. The checksum
>>>     computation algorithm is same for both steps. Let me describe how
>>>     I compute the checksum.
>>>
>>>
>>>      1. I get the CONSTANT_Class_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>> corresponding to a fix String constant, say "foo".
>>>      2. Since, the name of the class is used to refer to its types
>>>         members (fields/method), I get all CONSTANT_Fieldref_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
>>>      3. Next, since the naming of the fields, in Proxy classes, are
>>>         also suffixed by numbers, for example, `private static Method
>>>         m4`, we rewrite the UTF8 value of name in the
>>>         CONSTANT_NameAndType_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>>.
>>>      4. These fields can also have a random order so we simply sort
>>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
>>>         any differences due to ordering of fields/methods.
>>>      5. Simply sorting the byte array still had minute differences. I
>>>         could not understand why they existed even though values in
>>>         constant pool of the bytecode in allowlist and at runtime were
>>>         exactly the same after rewriting. The differences existed in
>>>         the bytes of the Code attribute of methods. I concluded that
>>>         the bytes stored some position information. To avoid this, I
>>>         created a subarray where I considered the bytes corresponding
>>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>>>         it resulted in the same checksums for both classfiles.
>>>
>>>
>>>     Let's understand the whole approach with an example of Proxy class.
>>>
>>>     `
>>>     public  final  class  $Proxy42  extends  Proxy  implements  org.apache.logging.log4j.core.config.plugins.Plugin  {
>>>     `
>>>
>>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>>>
>>>     When the same class is intercepted at runtime, say "$Proxy10", we
>>>     look for "Proxy_Plugin" in the allowlist and since the checksum
>>>     algorithm is same in both cases, we get a match and let the class
>>>     load.
>>>
>>>     This approach has seemed to work well for Proxy classes, Generated
>>>     Constructor Accessor (which is removed as you said). I also looked
>>>     at the species generated by method handles. I did not notice any
>>>     modification in them. Their name generation seemed okay to me. If
>>>     some new Species are generated, it is of course detected since it
>>>     is not in the allowlist.
>>>
>>>     I have not looked into LambdaMetafactory because I did not
>>>     encounter it as a problem so far, but I am aware its name
>>>     generation is also unstable. I have run my approach only a few
>>>     projects only. And for hidden classes, I assume the the agent
>>>     won't be able to intercept them so detecting them would be really
>>>     hard.
>>>
>>>
>>>     Regards,
>>>     Aman Sharma
>>>
>>>     PhD Student
>>>     KTH Royal Institute of Technology
>>>     School of Electrical Engineering and Computer Science (EECS)
>>>     Department of Theoretical Computer Science (TCS)
>>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>     ------------------------------------------------------------------------
>>>     *From:* liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>>
>>>     <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>> <mailto:liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>>
>>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
>>>     *To:* Aman Sharma; core-libs-dev
>>>     *Cc:* Martin Monperrus
>>>     *Subject:* Re: Deterministic naming of subclasses of
>>>     `java/lang/reflect/Proxy`
>>>     Hi Aman,
>>>     I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>     For your approach of an "allowlist" for Java runtime, project
>>>     Leyden is looking to generate a static image [1], that
>>>     > At run time it cannot load classes from outside the image, nor
>>>     can it create classes dynamically.
>>>     Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded and even object graphs; I
>>>     am not familiar with the details unfortunately.
>>>
>>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
>>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
>>>     replying this thread to core-libs-dev.
>>>
>>>     For your perceived problem that classes don't have unique names,
>>>     your description sounds dubious: GeneratedConstructorAccessor is
>>>     already retired by JEP 416 [2] in Java 18, and there are many
>>>     other cases in which JDK generates classes without stable names,
>>>     notoriously LambdaMetafactory (Gradle wished for cacheable
>>>     Lambdas); the same applies for the generated classes for
>>>     MethodHandle's LambdaForms (which carries implementation code for
>>>     LambdaForm). How are you checking the classes? It seems you are
>>>     not checking hidden classes. Proxy and Lambda classes are defined
>>>     by the caller's class loader, while LambdaForms are under JDK's
>>>     system class loader I think. We need to ensure you are correctly
>>>     finding all unstable classes before we can proceed.
>>>
>>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>
>>>     <https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>>
>>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
> <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
>>>
>>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>
>>>     <mailto:amansha at kth.se<mailto:amansha at kth.se> <mailto:amansha at kth.se>>> wrote:
>>>
>>>         Hi,
>>>
>>>
>>>         My name is Aman and I am a PhD student at KTH Royal Institute
>>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
>>>         <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>> project to
> strengthen the
>>>         software supply chain of multiple ecosystem. I particularly
>>>         focus on runtime integrity in Java. In this email, I want to
>>>         write about an issue I have discovered with /dynamic
>>>         generation of `java.lang.reflect.Proxy`classes/. I will
>>>         propose a solution and would love to hear the feedback from
>>>         the community. Let me know if this is the correct mailing-list
>>>         for such discussions. It seemed the most relevant from this
>>>         list <https://mail.openjdk.org/mailman/listinfo
> <https://mail.openjdk.org/mailman/listinfo>>.
>>>
>>>
>>>         *My research*
>>>
>>>         *
>>>         *
>>>
>>>         Java has features to load class on the fly - it can either
>>>         download or generate a class at runtime. These features are
>>>         useful for inner workings of JDK. For example, implementing
>>>         annotations, reflective access, etc. However, these features
>>>         have also contributed to critical vulnerabilities in the past
>>>         - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
>>>         All of these vulnerabilities have one thing in common - /a
>>>         class that was not known during build time was
>>>         downloaded/generated at runtime and loaded into JVM./
>>>
>>>
>>>         To defend against such vulnerabilities, we propose a solution
>>>         to /allowlist classes for runtime/. This allowlist will
>>>         contain an exhaustive list of classes that can be loaded by
>>>         the JVM and it will be enforced at runtime. We build this
>>>         allowlist from three sources:
>>>
>>>          1. All classes of all modules provided by the Java Standard
>>>             Library. We use ClassGraph
>>>             <https://github.com/classgraph/classgraph
> <https://github.com/classgraph/classgraph>> to scan the JDK.
>>>          2. We can take the source code and all dependencies of an
>>>             application. We use a software bill of materials to get
>>>             all the data.
>>>          3. Finally, we use run the test suite to include any runtime
>>>             downloaded/generated classes.
>>>
>>>         Such a list is able to prevent the above 3 CVEs because it
>>>         does not let the "unknown" bytecode to be loaded.
>>>
>>>         *Problem with generating such an allowlist*
>>>         *
>>>         *
>>>         The first two parts of the allowlist are easy to get. The
>>>         problem is with the third step where we want to allowlist all
>>>         the classes that could be downloaded or generated. Upon
>>>         running the test suite and hooking to the classes it loads, we
>>>         observer that the list consists of classes that are called
>>>         "com/sun/proxy/$Proxy2",
>>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>>>         many more. The purpose of these classes can be identifed. The
>>>         proxy class is created for to implement an annotation. The
>>>         accessor gives access to constructor of a class to the JVM.
>>>
>>>         When enforcing this allowlist at runtime, we see that the
>>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
>>>         allowlist and at runtime. In our case, we we are experimenting
>>>         with pdfbox <https://github.com/apache/pdfbox <https://github.com/apache/pdfbox>> so
> we created
>>>         the allowlist using its test suite. Then we enforced this
>>>         allowlist while running some of its subcommands. However,
>>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
>>>         at runtime that implemented the same interfaces and had the
>>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>>>         only differed in the name of the class, order of fields, and
>>>         types for fields references. This could happen because the
>>>         order of the loading of class is workload dependent, but it
>>>         causes problem to generate such an allowlist.
>>>
>>>         *Solution
>>>         *
>>>
>>>
>>>         We propose that naming of subclasses of
>>>         "java/lang/reflect/Proxy" should not be dependent upon the
>>>         order of loading. In order to do so, two issues can be fixed:
>>>
>>>          1. The naming of the class should not be based on AtomicLong
>>>             <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531 <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
>>>          2. Methods of the interfaces must be in a particular order.
>>>             Right now, they are not sorted in any particular order
>>>             <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178 <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>>.
>>>
>>>
>>>         These fixes will make proxy class generation deterministic
>>>         with respect to order of loading and won't be flagged at
>>>         runtime since the test suite would already detect them.
>>>
>>>         I would love to hear from the community about these ideas. If
>>>         in agreement, I would be happy to produce a patch. I have
>>>         discovered this issue with subclasses of
>>>         GeneratedConstructorAccessor
>>>         <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.
>>>
>>>         I also have PoCs for the above CVEs
>>>         <https://github.com/chains-project/exploits-for-sbom.exe
> <https://github.com/chains-project/exploits-for-sbom.exe>> and
>>>         a proof concept tool is being developed under the name
>>>         sbom.exe <https://github.com/chains-project/sbom.exe
> <https://github.com/chains-project/sbom.exe>> in case
>>>         any one wonders about the implementation. I would also be
>>>         happy to explain more.
>>>
>>>         Regards,
>>>         Aman Sharma
>>>
>>>         PhD Student
>>>         KTH Royal Institute of Technology
>>>         School of Electrical Engineering and Computer Science (EECS)
>>>         Department of Theoretical Computer Science (TCS)
>>>         <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240525/34f19a7d/attachment.htm>

From magnus.ihse.bursie at oracle.com  Tue May 28 16:08:56 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 28 May 2024 18:08:56 +0200
Subject: Hermetic Java project meeting
In-Reply-To: <CALrW1jzzQ8pkkXDmvM-9WbbdSiTrARZgnm6-x2V4zKC053RzgA@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>
 <779749fa-8427-4b48-b897-5210b36d5be8@oracle.com>
 <CALrW1jzzQ8pkkXDmvM-9WbbdSiTrARZgnm6-x2V4zKC053RzgA@mail.gmail.com>
Message-ID: <4b53e45f-5c26-4f22-a9dc-5276910e6430@oracle.com>

On 2024-05-07 06:04, Jiangli Zhou wrote:

>> 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?
>> In my <path>/leyden/build/linux-x86_64-server-slowdebug/images/jdk directory:
>
> $ mv lib/jvm.cfg lib/jvm.cfg.no_used
> $ find . | grep jvm.cfg
> ./lib/jvm.cfg.no_used
>
> $ bin/javastatic -cp <my_jar> HelloWorld
> HelloWorld

I was very much mislead by this. I was sure I hade made some mistake 
when I picked out the changes you have made for static builds (and 
removed all the other changes, e.g. for the hermetic jar files), since 
you said this worked for you. I have been scrutinizing the difference 
between your branch and mine, over and over again, without understanding 
what the difference could be.

Finally I did what I should have done at the very beginning, and 
actually tested building and running your branch.

It did not work either.

So why did you claim it worked? I kept digging, and I found out the 
reason. You had indeed implemented a fix for this, but only on Linux. I 
was testing on macOS. (It is also not implemented for Windows, but since 
I'm still struggling to find a way to create proper static builds there 
it is less of a problem for now.)

My branch worked just as well as your on Linux. I have now fixed so it 
works on macOS too. With this hurdle out of the way, I can get back to 
doing real work on the patch. Unfortunately this detour took far too 
much time. :-(

/Magnus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240528/fe395b92/attachment.htm>

From jianglizhou at google.com  Tue May 28 18:00:24 2024
From: jianglizhou at google.com (Jiangli Zhou)
Date: Tue, 28 May 2024 11:00:24 -0700
Subject: Hermetic Java project meeting
In-Reply-To: <4b53e45f-5c26-4f22-a9dc-5276910e6430@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>
 <CALrW1jwiQ=HOknmPehQQxc5W3mBSNfX+dzeGBaf73=g-h7hDgg@mail.gmail.com>
 <779749fa-8427-4b48-b897-5210b36d5be8@oracle.com>
 <CALrW1jzzQ8pkkXDmvM-9WbbdSiTrARZgnm6-x2V4zKC053RzgA@mail.gmail.com>
 <4b53e45f-5c26-4f22-a9dc-5276910e6430@oracle.com>
Message-ID: <CALrW1jxg6H_aBGJ+7DLdJkxqMHfqLeA5tjrT2wVWkd0ABrGhFQ@mail.gmail.com>

On Tue, May 28, 2024 at 9:09?AM Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> On 2024-05-07 06:04, Jiangli Zhou wrote:
>
> 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?
> In my <path>/leyden/build/linux-x86_64-server-slowdebug/images/jdk directory:
>
> $ mv lib/jvm.cfg lib/jvm.cfg.no_used $ find . | grep jvm.cfg
> ./lib/jvm.cfg.no_used $ bin/javastatic -cp <my_jar> HelloWorld HelloWorld
>
> I was very much mislead by this. I was sure I hade made some mistake when
> I picked out the changes you have made for static builds (and removed all
> the other changes, e.g. for the hermetic jar files), since you said this
> worked for you. I have been scrutinizing the difference between your branch
> and mine, over and over again, without understanding what the difference
> could be.
>
> Finally I did what I should have done at the very beginning, and actually
> tested building and running your branch.
>
> It did not work either.
>
> So why did you claim it worked? I kept digging, and I found out the
> reason. You had indeed implemented a fix for this, but only on Linux. I was
> testing on macOS. (It is also not implemented for Windows, but since I'm
> still struggling to find a way to create proper static builds there it is
> less of a problem for now.)
>
> My branch worked just as well as your on Linux. I have now fixed so it
> works on macOS too. With this hurdle out of the way, I can get back to
> doing real work on the patch. Unfortunately this detour took far too much
> time. :-(
>

Mystery solved! Yes, our prototype was for linux-x64 only (communicated in
https://mail.openjdk.org/pipermail/leyden-dev/2023-February/000106.html and
our discussion meetings). I think I was not clear that you were testing on
macOS.

The supported platform was also discussed in the hermetic Java meetings. My
understanding was that we can focus on Linux (or unix-like) initially.
Let's get the initial integration point support for Linux. Glad to see that
you are making progress! Please let me know if you are running into any
other issues.

Best,
Jiangli

> /Magnus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240528/a7178231/attachment.htm>

From duke at openjdk.org  Wed May 29 17:24:54 2024
From: duke at openjdk.org (duke)
Date: Wed, 29 May 2024 17:24:54 GMT
Subject: git: openjdk/leyden: premain: Added checks for G1GC during new
 workflow training run
Message-ID: <60c20413-2c9d-4201-80d3-94e7ccaf381c@openjdk.org>

Changeset: 4faa7202
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-05-29 10:22:19 +0000
URL:       https://git.openjdk.org/leyden/commit/4faa72029abb86b55cb33b00acf9f3a18ade4b77

Added checks for G1GC during new workflow training run

! README.md
! src/hotspot/share/cds/metaspaceShared.cpp


From magnus.ihse.bursie at oracle.com  Thu May 30 13:03:14 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 30 May 2024 15:03:14 +0200
Subject: Hermetic Java project meeting
In-Reply-To: <CALrW1jw=NNkk9Tars4UZh3keCvcpRgWQeqprxJQz=vGUMZDvOQ@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>
 <779749fa-8427-4b48-b897-5210b36d5be8@oracle.com>
 <CALrW1jzzQ8pkkXDmvM-9WbbdSiTrARZgnm6-x2V4zKC053RzgA@mail.gmail.com>
 <6090f2aa-1480-4706-9281-035579a933af@oracle.com>
 <CALrW1jyeJctmpV6WM+jQX8gqh0=AmfbfuD8iThH0pie5uF=hAg@mail.gmail.com>
 <CALrW1jw=NNkk9Tars4UZh3keCvcpRgWQeqprxJQz=vGUMZDvOQ@mail.gmail.com>
Message-ID: <b2b3d3f4-1d6e-49bc-bd08-a355c2b7dbb2@oracle.com>

On 2024-05-21 20:51, Jiangli Zhou wrote:

> Magnus will send out his changes as PR draft for initial review for 
> deciding on how to move forward with the non-makefile changes. 

This is now published in https://github.com/openjdk/jdk/pull/19478.

/Magnus


From duke at openjdk.org  Fri May 31 04:26:41 2024
From: duke at openjdk.org (duke)
Date: Fri, 31 May 2024 04:26:41 GMT
Subject: git: openjdk/leyden: premain: 2 new changesets
Message-ID: <b092d6c6-56cf-4e79-a8cb-70b24b65ef31@openjdk.org>

Changeset: f7d6f17a
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-05-30 20:18:34 +0000
URL:       https://git.openjdk.org/leyden/commit/f7d6f17abd2228dd53dc2dc64ce4fd8fdb89d1a8

Removed Leyden-specific workaround in test cases

! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesAsCollectorTest.java
! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesCastFailureTest.java
! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java
! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesInvokersTest.java
! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesPermuteArgumentsTest.java
! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java

Changeset: 7e9d14f0
Author:    Ioi Lam <iklam at openjdk.org>
Committer: iklam <ilam3388 at gmail.com>
Date:      2024-05-30 21:21:24 +0000
URL:       https://git.openjdk.org/leyden/commit/7e9d14f002b5f46bd8680e792e80d71e21d0f506

8332340: Add JavacBench as a test case for CDS

Reviewed-by: ccheung, matsaave

! test/hotspot/jtreg/runtime/cds/appcds/applications/JavacBenchApp.java
! test/lib/jdk/test/lib/StringArrayUtils.java
! test/lib/jdk/test/lib/cds/CDSAppTester.java


From duke at openjdk.org  Fri May 31 05:59:45 2024
From: duke at openjdk.org (duke)
Date: Fri, 31 May 2024 05:59:45 GMT
Subject: git: openjdk/leyden: premain: 8333222: Allow SerialGC and ParallelGC
 to be used in Leyden training run
Message-ID: <59bc0c8b-8dac-46b8-ba92-39f88fb57970@openjdk.org>

Changeset: c67940c7
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-05-30 22:55:47 +0000
URL:       https://git.openjdk.org/leyden/commit/c67940c709d4dfb0d5295f73971d33d40eeea527

8333222: Allow SerialGC and ParallelGC to be used in Leyden training run

! src/hotspot/share/cds/archiveHeapWriter.cpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/heapShared.hpp
! src/hotspot/share/cds/metaspaceShared.cpp
+ test/hotspot/jtreg/runtime/cds/appcds/leyden/LeydenGCFlags.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/IncompatibleOptions.java
! test/lib/jdk/test/lib/cds/CDSAppTester.java