From divcesar at gmail.com  Mon Sep  2 18:55:42 2024
From: divcesar at gmail.com (=?UTF-8?B?Q8Opc2Fy?=)
Date: Mon, 2 Sep 2024 11:55:42 -0700
Subject: Some offhand questions
Message-ID: <CAHN8PeeFDnPTGp2vBg9eq4fO0U39atSPD-BQvBGPwik-S_akhA@mail.gmail.com>

Thank you Dan, John, for the detailed answers.

> Did you have other thoughts on how such a score could be computed?

I have some ideas, but for now I was just curious whether the group
would think this is something that makes sense.

> [...] That means we should work on code caching first, then work on managing/curating/filtering/sizing the AOT code cache.

Sounds good to me.


Thanks,
C?sar.

From divcesar at gmail.com  Mon Sep  2 18:59:01 2024
From: divcesar at gmail.com (=?UTF-8?B?Q8Opc2Fy?=)
Date: Mon, 2 Sep 2024 11:59:01 -0700
Subject: Encapsulating JVM Options
Message-ID: <CAHN8PecsTGBVjRU6uhwHZcJp_0e7T_Qxp_d6LBS4cjGFK62wBg@mail.gmail.com>

Thanks again, John for another helpful detailed explanation!

I created this RFE to track this work:
https://bugs.openjdk.org/browse/JDK-8339350

I'm looking forward to hearing what others think about this work stream.


Thanks,
C?sar.

From magnus.ihse.bursie at oracle.com  Tue Sep  3 13:08:14 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 3 Sep 2024 15:08:14 +0200
Subject: PR with static-jdk launcher
Message-ID: <525ef7ed-fba6-4a7a-9257-ec101a9afa00@oracle.com>

Hi,

I just wanted to let you know that there is now a PR with an initial 
implementation of a static java launcher:

https://github.com/openjdk/jdk/pull/20837

Some noteworthy limitations:

1) Support for hiding local symbols in static libraries are not yet 
implemented. This mean that there are symbol clashes between some 
libraries. As a result, I have temporarily disabled a few libraries. 
This in turn means that the native code is not complete, so not all JDK 
functionality is present. How much is missing depends on which platform 
you run.

2) Only the java launcher is present, no other JDK launchers (including 
javac) are present. This means that it is not possible to run JTReg 
tests. I have an idea on how to address this in the future.

3) On Windows, changes need to be done in the launcher code; similar to 
what has been done for Linux and macOS. As a result of this, the static 
launcher builds just fine, but crashes at startup. I don't think it is 
hard to fix, but I have not prioritized this. The reason is that the 
inclusion of a working static launcher for macOS and Linux will help the 
Hermetic Java project along, and the Windows launcher can be fixed in 
the meantime.

4) This is not tested on AIX nor any other platforms apart from Linux, 
macOS and Windows. It is tested with both gcc and clang on Linux.

5) There are still a lot of untidy and badly structured code surrounding 
static libraries. I hope to address some of this mess as follow-up work.

6) This PR does not address the issue that all native files are compiled 
twice. That is a completely orthogonal problem to this.

/Magnus


From duke at openjdk.org  Tue Sep  3 17:53:09 2024
From: duke at openjdk.org (duke)
Date: Tue, 3 Sep 2024 17:53:09 GMT
Subject: git: openjdk/leyden: hermetic-java-runtime: 23 new changesets
Message-ID: <ca24bbf3-2a1b-45d4-b27d-9aa49ecb3ac5@openjdk.org>

Changeset: 4675913e
Branch: hermetic-java-runtime
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2024-08-30 01:06:00 +0000
URL:       https://git.openjdk.org/leyden/commit/4675913edb16ec1dde5f0ba2dfcfada134ce17f1

8339237: RISC-V: Builds fail after JDK-8339120

Reviewed-by: fyang

! src/hotspot/cpu/riscv/c1_Runtime1_riscv.cpp

Changeset: f927c121
Branch: hermetic-java-runtime
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Date:      2024-08-30 06:21:49 +0000
URL:       https://git.openjdk.org/leyden/commit/f927c1210ee0675bb1196572177ffb505826d57a

8339154: Cleanups and JUnit conversion of test/jdk/java/util/zip/Available.java

Reviewed-by: lancea

! test/jdk/java/util/zip/Available.java

Changeset: b9e65f98
Branch: hermetic-java-runtime
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-08-30 06:47:49 +0000
URL:       https://git.openjdk.org/leyden/commit/b9e65f982fe6ae69d3912f32465a688d67c1c765

8337662: Improve os::print_hex_dump for printing Instructions sections

Reviewed-by: stuefe, lucy

! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! test/hotspot/gtest/runtime/test_os.cpp

Changeset: b8727181
Branch: hermetic-java-runtime
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-08-30 08:11:49 +0000
URL:       https://git.openjdk.org/leyden/commit/b8727181f3ceac6f37272a1152f267ed1b6e2297

8338301: Error recovery and reporting should be improved for erroneous implicitly declared classes

Reviewed-by: cstein, vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/langtools/tools/javac/ImplicitClass/ErrorRecovery.java
+ test/langtools/tools/javac/diags/examples/ClassMethodOrFieldExpected.java

Changeset: bb28b0d2
Branch: hermetic-java-runtime
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-08-30 08:58:07 +0000
URL:       https://git.openjdk.org/leyden/commit/bb28b0d2292c0f45decfaac0fb2f4c4284e9c666

8338404: Cross-compilation to different endianness fails after JDK-8318913

Reviewed-by: erikj, fbredberg

! make/CreateJmods.gmk
! make/InterimImage.gmk

Changeset: 2abe2ff6
Branch: hermetic-java-runtime
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-08-30 08:58:18 +0000
URL:       https://git.openjdk.org/leyden/commit/2abe2ff69b205ccaf502bf8b6de3ce9e1260c386

8339235: Fix indentation in build system

Reviewed-by: erikj

! make/CompileInterimLangtools.gmk
! make/CompileJavaModules.gmk
! make/InitSupport.gmk
! make/autoconf/basic_tools.m4
! make/autoconf/boot-jdk.m4
! make/autoconf/flags-ldflags.m4
! make/autoconf/jdk-options.m4
! make/autoconf/jdk-version.m4
! make/autoconf/lib-bundled.m4
! make/autoconf/lib-freetype.m4
! make/autoconf/lib-hsdis.m4
! make/autoconf/libraries.m4
! make/autoconf/platform.m4
! make/autoconf/toolchain_microsoft.m4
! make/common/FindTests.gmk
! make/common/JavaCompilation.gmk
! make/common/JdkNativeCompilation.gmk
! make/common/MakeBase.gmk
! make/common/Modules.gmk
! make/common/Utils.gmk
! make/common/native/DebugSymbols.gmk
! make/hotspot/gensrc/GensrcAdlc.gmk
! make/hotspot/lib/JvmFeatures.gmk
! make/modules/java.desktop/lib/ClientLibraries.gmk
! make/modules/jdk.accessibility/Launcher.gmk

Changeset: 92c4704e
Branch: hermetic-java-runtime
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-08-30 10:18:19 +0000
URL:       https://git.openjdk.org/leyden/commit/92c4704edf75534b825765d156a7f70377ccb3bb

8339166: java/lang/String/concat/HiddenClassUnloading.java fails on AIX and Linux ppc64le after JDK-8336856

Reviewed-by: redestad, mdoerr

! test/jdk/java/lang/String/concat/HiddenClassUnloading.java

Changeset: 3a352b82
Branch: hermetic-java-runtime
Author:    David Schlosnagle <davids at palantir.com>
Committer: Erik Gahlin <egahlin at openjdk.org>
Date:      2024-08-30 12:36:33 +0000
URL:       https://git.openjdk.org/leyden/commit/3a352b82591eb522c24108de95e42a3d1e5ceb3a

8339191: JFR: Bulk read support for ChunkInputStream

Reviewed-by: egahlin

! src/jdk.jfr/share/classes/jdk/jfr/internal/ChunkInputStream.java
+ test/jdk/jdk/jfr/api/consumer/TestChunkInputStreamBulkRead.java

Changeset: 2fb83055
Branch: hermetic-java-runtime
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-08-30 14:47:29 +0000
URL:       https://git.openjdk.org/leyden/commit/2fb830553f219e59a44c140e2441695a0d79c404

8339319: ProblemList runtime/exceptionMsgs/NoClassDefFoundError/NoClassDefFoundErrorTest.java

Reviewed-by: dfuchs, dcubed

! test/hotspot/jtreg/ProblemList.txt

Changeset: a528c4b3
Branch: hermetic-java-runtime
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-08-30 16:43:16 +0000
URL:       https://git.openjdk.org/leyden/commit/a528c4b370be1e7730778268cf8c52ffcfd27048

8339156: Use more fine-granular clang unused warnings

Reviewed-by: erikj, kbarrett

! make/autoconf/flags-cflags.m4
! make/common/TestFilesCompilation.gmk
! make/common/modules/LauncherCommon.gmk
! make/hotspot/lib/CompileJvm.gmk
! make/modules/java.base/Lib.gmk
! make/modules/java.base/lib/CoreLibraries.gmk
! make/modules/java.desktop/Lib.gmk
! make/modules/java.desktop/lib/AwtLibraries.gmk
! make/modules/java.desktop/lib/ClientLibraries.gmk
! make/modules/java.management/Lib.gmk
! make/modules/java.security.jgss/Lib.gmk
! make/modules/jdk.crypto.cryptoki/Lib.gmk
! make/modules/jdk.hotspot.agent/Lib.gmk
! make/modules/jdk.jdwp.agent/Lib.gmk
! make/modules/jdk.jpackage/Lib.gmk
! make/modules/jdk.management/Lib.gmk

Changeset: fef1ef7d
Branch: hermetic-java-runtime
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-08-30 17:17:10 +0000
URL:       https://git.openjdk.org/leyden/commit/fef1ef7dfe1aed7729b182b2fc8d0dda7d546a56

6426678: (spec) File.createTempFile(prefix, suffix, dir) needs clarification for illegal symbols in suffix

Reviewed-by: alanb

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

Changeset: 25e03b52
Branch: hermetic-java-runtime
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-08-30 17:28:28 +0000
URL:       https://git.openjdk.org/leyden/commit/25e03b52094f46f89f2fe8f20e7e5622928add5f

8339115: Rename TypeKind enum constants to follow code style

Reviewed-by: asotona

! make/jdk/src/classes/build/tools/taglet/JSpec.java
! src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
! src/java.base/share/classes/java/lang/classfile/Opcode.java
! src/java.base/share/classes/java/lang/classfile/TypeKind.java
! src/java.base/share/classes/java/lang/classfile/components/snippet-files/PackageSnippets.java
! src/java.base/share/classes/java/lang/classfile/constantpool/DoubleEntry.java
! src/java.base/share/classes/java/lang/classfile/constantpool/FloatEntry.java
! src/java.base/share/classes/java/lang/classfile/constantpool/IntegerEntry.java
! src/java.base/share/classes/java/lang/classfile/constantpool/LoadableConstantEntry.java
! src/java.base/share/classes/java/lang/classfile/constantpool/LongEntry.java
! src/java.base/share/classes/java/lang/classfile/instruction/ArrayLoadInstruction.java
! src/java.base/share/classes/java/lang/classfile/instruction/ArrayStoreInstruction.java
! src/java.base/share/classes/java/lang/classfile/instruction/NewPrimitiveArrayInstruction.java
! src/java.base/share/classes/java/lang/classfile/snippet-files/PackageSnippets.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/LambdaForm.java
! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
! src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/CodeLocalsShifterImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/CodeStackTrackerImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java
! src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/CodeWriter.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
! test/jdk/jdk/classfile/AdvancedTransformationsTest.java
! test/jdk/jdk/classfile/ArrayTest.java
! test/jdk/jdk/classfile/BuilderBlockTest.java
! test/jdk/jdk/classfile/BuilderTryCatchTest.java
! test/jdk/jdk/classfile/StackTrackerTest.java
! test/jdk/jdk/classfile/TempConstantPoolBuilderTest.java
! test/jdk/jdk/classfile/Utf8EntryTest.java
! test/jdk/jdk/classfile/helpers/ClassRecord.java
! test/jdk/jdk/classfile/helpers/RebuildingTransformation.java
! test/micro/org/openjdk/bench/jdk/classfile/Write.java

Changeset: b840b130
Branch: hermetic-java-runtime
Author:    Justin Lu <jlu at openjdk.org>
Date:      2024-08-30 18:28:53 +0000
URL:       https://git.openjdk.org/leyden/commit/b840b130df7ccb64d4615460c0654a6315e9302f

8338882: Clarify matching order of MessageFormat subformat factory styles

Reviewed-by: naoto

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

Changeset: 4f071ce0
Branch: hermetic-java-runtime
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-08-31 01:13:07 +0000
URL:       https://git.openjdk.org/leyden/commit/4f071ce074b934d5610e213d348cff8326f1499d

8311163: Parallel: Improve large object handling during evacuation

Reviewed-by: tschatzl, ayang

! src/hotspot/share/gc/parallel/psPromotionManager.cpp
! src/hotspot/share/gc/parallel/psPromotionManager.hpp
! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp
! src/hotspot/share/gc/shared/partialArrayState.hpp
! src/hotspot/share/gc/shared/taskqueue.hpp

Changeset: 392bdd57
Branch: hermetic-java-runtime
Author:    Fei Yang <fyang at openjdk.org>
Date:      2024-08-31 01:44:17 +0000
URL:       https://git.openjdk.org/leyden/commit/392bdd5734e0ad4e616d52bb7bcafcf85dccbf34

8339248: RISC-V: Remove li64 macro assembler routine and related code

Reviewed-by: rehn, fjiang, luhenry

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

Changeset: 92aafb43
Branch: hermetic-java-runtime
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-09-01 16:13:53 +0000
URL:       https://git.openjdk.org/leyden/commit/92aafb43424321d8f2552aa34a9a3df291abf992

8338934: vmTestbase/nsk/jvmti/*Field*Watch/TestDescription.java tests timeout intermittently

Reviewed-by: sspitsyn, amenkov

! src/hotspot/share/prims/jvmtiEnv.cpp
! src/hotspot/share/prims/jvmtiEventController.cpp
! src/hotspot/share/runtime/mutexLocker.cpp

Changeset: 9d7d85a6
Branch: hermetic-java-runtime
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2024-09-02 01:23:50 +0000
URL:       https://git.openjdk.org/leyden/commit/9d7d85a6aa20ed95166f5f2f951597bca1fde841

8339298: Remove unused function declaration poll_for_safepoint

Reviewed-by: fyang, chagedorn

! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.hpp
! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.hpp

Changeset: a136a85b
Branch: hermetic-java-runtime
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-09-02 09:14:36 +0000
URL:       https://git.openjdk.org/leyden/commit/a136a85b6f5bbc92727883693c1ce31c37a82fd5

8338768: Introduce runtime lookup to check for static builds

Co-authored-by: Magnus Ihse Bursie <ihse at openjdk.org>
Co-authored-by: Jiangli Zhou <jiangli at openjdk.org>
Reviewed-by: prr, jiangli, alanb

! make/modules/jdk.jdwp.agent/Lib.gmk
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/share/compiler/disassembler.cpp
! src/hotspot/share/include/jvm.h
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/java.hpp
+ src/hotspot/share/runtime/linkType.cpp
! src/java.base/macosx/native/libjli/java_md_macosx.m
! src/java.base/share/native/libjli/jli_util.h
+ src/java.base/share/native/libjli/link_type.c
! src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c
! src/jdk.jdwp.agent/share/native/libjdwp/transport.c

Changeset: 03ba37e6
Branch: hermetic-java-runtime
Author:    Aleksei Efimov <aefimov at openjdk.org>
Date:      2024-09-02 09:32:10 +0000
URL:       https://git.openjdk.org/leyden/commit/03ba37e60ce08def6afd172efc1cdbbcc856c633

8339169: Remove NaiveHuffman coder

Reviewed-by: djelinski, dfuchs

- src/java.net.http/share/classes/jdk/internal/net/http/hpack/NaiveHuffman.java

Changeset: b1163bcc
Branch: hermetic-java-runtime
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-09-02 14:52:04 +0000
URL:       https://git.openjdk.org/leyden/commit/b1163bcc88a5b88b9a56d5584310f1d679690ab2

8256211: assert fired in java/net/httpclient/DependentPromiseActionsTest (infrequent)

Reviewed-by: jpai

! test/jdk/java/net/httpclient/DependentPromiseActionsTest.java

Changeset: 0e6bb514
Branch: hermetic-java-runtime
Author:    Joshua Zhu <jzhu at openjdk.org>
Committer: Andrew Dinn <adinn at openjdk.org>
Date:      2024-09-02 15:37:58 +0000
URL:       https://git.openjdk.org/leyden/commit/0e6bb514c8ec7c4a7100fe06eaa9e954a74fda30

8339063: [aarch64] Skip verify_sve_vector_length after native calls if SVE supports 128 bits VL only

Reviewed-by: adinn, fgao

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/aarch64_vector.ad
! src/hotspot/cpu/aarch64/aarch64_vector_ad.m4
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/register_aarch64.hpp
! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp
! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp

Changeset: 62dad3a9
Branch: hermetic-java-runtime
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-09-02 17:57:02 +0000
URL:       https://git.openjdk.org/leyden/commit/62dad3a9ea222b0fbf15668d6e7b1c4ed61b2532

8339351: Remove duplicate line in FileMapHeader::print

Reviewed-by: dholmes

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

Changeset: 77457002
Branch: hermetic-java-runtime
Author:    Jiangli Zhou <jianglizhou at google.com>
Date:      2024-09-03 10:48:40 +0000
URL:       https://git.openjdk.org/leyden/commit/7745700297b80ffa308d565a458c8600af4911cb

Merge branch 'master' into hermetic-java-runtime

! make/autoconf/flags-ldflags.m4
! make/autoconf/lib-bundled.m4
! make/autoconf/lib-freetype.m4
! make/modules/java.base/lib/CoreLibraries.gmk
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/runtime/java.hpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c
! make/autoconf/flags-ldflags.m4
! make/autoconf/lib-bundled.m4
! make/autoconf/lib-freetype.m4
! make/modules/java.base/lib/CoreLibraries.gmk
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/runtime/java.hpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c


From ioi.lam at oracle.com  Tue Sep  3 20:48:09 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Tue, 3 Sep 2024 13:48:09 -0700
Subject: Windows build of Leyden EA
In-Reply-To: <CABKVO1X1Qd2jxSYZ+s6z6jt92n6ovBw90N_AQDaWbf9+-Kj1gg@mail.gmail.com>
References: <CABKVO1X1Qd2jxSYZ+s6z6jt92n6ovBw90N_AQDaWbf9+-Kj1gg@mail.gmail.com>
Message-ID: <a9177a49-8255-4330-968f-b65a4f10a447@oracle.com>

The current tip of the Leyden "premain" branch builds with Windows. We 
have only done some simple testing of running all the CDS tests with the 
Windows build and didn't find any obvious problems. However, Windows is 
not regularly used by the Leyden developers so it's not as well tested 
as the Linux and Mac builds.

I guess whether a Windows build will be included in the next EA would 
depend on the user demand.

Thanks

- Ioi


On 8/25/24 9:07 AM, ski n wrote:
>
> I just watched the presentation at JVMLS on the status of project 
> Leyden on YouTube:
>
> https://www.youtube.com/watch?v=OOPSU4LnKg0
>
> In the talk, they pointed at the EA that came out last June. 
> Currently, only Linux and Mac builds are available.
>
> When will the next EA come available, and will this also contain a 
> Windows build?
>
> Raymond

From raymondmeester at gmail.com  Wed Sep  4 06:56:29 2024
From: raymondmeester at gmail.com (ski n)
Date: Wed, 4 Sep 2024 08:56:29 +0200
Subject: Windows build of Leyden EA
In-Reply-To: <a9177a49-8255-4330-968f-b65a4f10a447@oracle.com>
References: <CABKVO1X1Qd2jxSYZ+s6z6jt92n6ovBw90N_AQDaWbf9+-Kj1gg@mail.gmail.com>
 <a9177a49-8255-4330-968f-b65a4f10a447@oracle.com>
Message-ID: <CABKVO1V4UvUHZcYTyycgZkN_uc4Kx7SuHD8Q5VuftNWKdGgqsg@mail.gmail.com>

That's great. I think the Windows community, especially for developers, is
still big. I, and other Java developers, would happy to do some testing.

Raymond

On Tue, Sep 3, 2024 at 10:48?PM <ioi.lam at oracle.com> wrote:

> The current tip of the Leyden "premain" branch builds with Windows. We
> have only done some simple testing of running all the CDS tests with the
> Windows build and didn't find any obvious problems. However, Windows is
> not regularly used by the Leyden developers so it's not as well tested
> as the Linux and Mac builds.
>
> I guess whether a Windows build will be included in the next EA would
> depend on the user demand.
>
> Thanks
>
> - Ioi
>
>
> On 8/25/24 9:07 AM, ski n wrote:
> >
> > I just watched the presentation at JVMLS on the status of project
> > Leyden on YouTube:
> >
> > https://www.youtube.com/watch?v=OOPSU4LnKg0
> >
> > In the talk, they pointed at the EA that came out last June.
> > Currently, only Linux and Mac builds are available.
> >
> > When will the next EA come available, and will this also contain a
> > Windows build?
> >
> > Raymond
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240904/b9de0c29/attachment.htm>

From shade at openjdk.org  Wed Sep  4 21:53:16 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Sep 2024 21:53:16 GMT
Subject: RFR: Fix SCCache closing races
Message-ID: <292kZbD9f1qE0V24gStvcVuraPqxySE8k51sr801ZuM=.67f8ed84-a97e-446d-940e-d9e25294f36a@github.com>

I have been scratching my head why Leyden builds crash with multiple iterations of `HelloStream` example.

The crashes are of various shapes, but they have a similar clue: it happens when we touch `SCCache` when it was already closed: `hs_err` shows we have called `before_exit`, `gdb` shows `SCCache::_cache` is already `nullptr`, but the crashes are in compiler code that accesses `SCCache`.

Looking at `SCCache` closing code, I found two major bugs:

1. For cache writer side, we piggyback on `Compile_lock` to abitrate the access to maybe-closing cache. That does not work: in `ciEnv::register_method`, we already have `SCEntry*` in our hands, and once we acquire the `Compile_lock`, the whole `SCCache` might be gone, `SCEntry*` points to garbage, and we SEGV. This one is easy to solve: check that cache is still on, under the lock.

2. For cache reader side, we have a `reading_nmethod` counter, which is supposed to track how many nmethod readers are currently active. Unfortunately, this is still racy: nothing prevents new nmethod readers to appear _"after"_ we closed the cache. So those nmethod readers can access the cache in invalid state. There is also piggybacking on `Compilation_lock`, which AFAICS is for WhiteBox paths! So this is not great. I replaced the whole thing with carefully tracking the nmethod reader counts, and making sure we have the phasing right.

Eliminating `Compilation_lock` wait improves performance and variance on short workloads as well. Observe:


$ rm -f app.cds*; taskset -c 0-7 hyperfine -w 50 -r 100 "build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp hellostream.jar HelloStream"

# BEFORE (this also crashes every so often)
Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp hellostream.jar HelloStream
  Time (mean ? ?):      24.0 ms ?   4.3 ms    [User: 14.1 ms, System: 9.8 ms]
  Range (min ? max):    17.0 ms ?  27.3 ms    100 runs
 
  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

# AFTER
Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp hellostream.jar HelloStream
  Time (mean ? ?):      17.3 ms ?   0.3 ms    [User: 10.8 ms, System: 9.4 ms]
  Range (min ? max):    16.8 ms ?  18.6 ms    100 runs


Additional testing:
 - [x] Linux x86_64 server fastdebug, `runtime/cds`

-------------

Commit messages:
 - Fix for reader side
 - Fix for writer side

Changes: https://git.openjdk.org/leyden/pull/13/files
  Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=13&range=00
  Stats: 101 lines in 3 files changed: 84 ins; 5 del; 12 mod
  Patch: https://git.openjdk.org/leyden/pull/13.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/13/head:pull/13

PR: https://git.openjdk.org/leyden/pull/13

From shade at openjdk.org  Wed Sep  4 21:53:09 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Sep 2024 21:53:09 GMT
Subject: RFR: Enable 1-step workflow with Shenandoah GC
Message-ID: <o-jjFUp6XKu9fFF9_BDQ6Gf2xi4I4I5cUJlvq_evKrY=.8419a68c-ae5f-43f0-b332-1d421472d9c7@github.com>

WIP, includes upstream [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650).

I checked this works well:


#!/bin/bash
make images
J=build/macosx-aarch64-server-fastdebug/images/jdk/bin/java
rm -fv JavacBenchApp.cds*
$J -XX:+UseShenandoahGC -XX:CacheDataStore=JavacBenchApp.cds -cp JavacBenchApp.jar JavacBenchApp 50
$J -XX:+UseShenandoahGC -XX:CacheDataStore=JavacBenchApp.cds -cp JavacBenchApp.jar JavacBenchApp 50


I'll look around what other tests I need to run.

-------------

Commit messages:
 - Temporary drop the alignment, so that tests work
 - Shenandoah support

Changes: https://git.openjdk.org/leyden/pull/8/files
  Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=8&range=00
  Stats: 48 lines in 7 files changed: 33 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/leyden/pull/8.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/8/head:pull/8

PR: https://git.openjdk.org/leyden/pull/8

From kvn at openjdk.org  Wed Sep  4 21:53:17 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 4 Sep 2024 21:53:17 GMT
Subject: RFR: Fix SCCache closing races
In-Reply-To: <292kZbD9f1qE0V24gStvcVuraPqxySE8k51sr801ZuM=.67f8ed84-a97e-446d-940e-d9e25294f36a@github.com>
References: <292kZbD9f1qE0V24gStvcVuraPqxySE8k51sr801ZuM=.67f8ed84-a97e-446d-940e-d9e25294f36a@github.com>
Message-ID: <-Nc5VbDx07wncjS83CruVVwuOUMB7LKnIbyU94Uj3_c=.167a2897-4000-4f16-879d-366085439cb5@github.com>

On Wed, 4 Sep 2024 12:46:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have been scratching my head why Leyden builds crash with multiple iterations of `HelloStream` example.
> 
> The crashes are of various shapes, but they have a similar clue: it happens when we touch `SCCache` when it was already closed: `hs_err` shows we have called `before_exit`, `gdb` shows `SCCache::_cache` is already `nullptr`, but the crashes are in compiler code that accesses `SCCache`.
> 
> Looking at `SCCache` closing code, I found two major bugs:
> 
> 1. For cache writer side, we piggyback on `Compile_lock` to abitrate the access to maybe-closing cache. That does not work: in `ciEnv::register_method`, we already have `SCEntry*` in our hands, and once we acquire the `Compile_lock`, the whole `SCCache` might be gone, `SCEntry*` points to garbage, and we SEGV. This one is easy to solve: check that cache is still on, under the lock.
> 
> 2. For cache reader side, we have a `reading_nmethod` counter, which is supposed to track how many nmethod readers are currently active. Unfortunately, this is still racy: nothing prevents new nmethod readers to appear _"after"_ we closed the cache. So those nmethod readers can access the cache in invalid state. There is also piggybacking on `Compilation_lock`, which AFAICS is for WhiteBox paths! So this is not great. I replaced the whole thing with carefully tracking the nmethod reader counts, and making sure we have the phasing right.
> 
> Eliminating `Compilation_lock` wait improves performance and variance on short workloads as well. Observe:
> 
> 
> $ rm -f app.cds*; taskset -c 0-7 hyperfine -w 50 -r 100 "build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp hellostream.jar HelloStream"
> 
> # BEFORE (this also crashes every so often)
> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp hellostream.jar HelloStream
>   Time (mean ? ?):      24.0 ms ?   4.3 ms    [User: 14.1 ms, System: 9.8 ms]
>   Range (min ? max):    17.0 ms ?  27.3 ms    100 runs
>  
>   Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.
> 
> # AFTER
> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp hellostream....

Looks good. Thank you for fixing it.

Please, use [premain] prefix in subjects which we use in JBS for our bugs.
And Ioi filed SKARA request to automatically send our PR requests to Leyden-dev mailing list because I missed this PR.

src/hotspot/share/code/SCCache.cpp line 4198:

> 4196:     int cur = Atomic::load(&_nmethod_readers);
> 4197:     int upd = -(cur + 1);
> 4198:     if (cur >= 0 && Atomic::cmpxchg(&_nmethod_readers, cur, upd) == cur) {

Clever.

-------------

Marked as reviewed by kvn (Committer).

PR Review: https://git.openjdk.org/leyden/pull/13#pullrequestreview-2281435783
PR Comment: https://git.openjdk.org/leyden/pull/13#issuecomment-2330191492
PR Review Comment: https://git.openjdk.org/leyden/pull/13#discussion_r1744526295

From shade at openjdk.org  Wed Sep  4 21:53:18 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Sep 2024 21:53:18 GMT
Subject: RFR: Fix SCCache closing races
In-Reply-To: <292kZbD9f1qE0V24gStvcVuraPqxySE8k51sr801ZuM=.67f8ed84-a97e-446d-940e-d9e25294f36a@github.com>
References: <292kZbD9f1qE0V24gStvcVuraPqxySE8k51sr801ZuM=.67f8ed84-a97e-446d-940e-d9e25294f36a@github.com>
Message-ID: <xo7I4YCBTqu7KttDe1lj2_-IFSMJXcIfyiX1CmZysuk=.a69b0069-188e-41ca-a9bc-7f802550df1b@github.com>

On Wed, 4 Sep 2024 12:46:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have been scratching my head why Leyden builds crash with multiple iterations of `HelloStream` example.
> 
> The crashes are of various shapes, but they have a similar clue: it happens when we touch `SCCache` when it was already closed: `hs_err` shows we have called `before_exit`, `gdb` shows `SCCache::_cache` is already `nullptr`, but the crashes are in compiler code that accesses `SCCache`.
> 
> Looking at `SCCache` closing code, I found two major bugs:
> 
> 1. For cache writer side, we piggyback on `Compile_lock` to abitrate the access to maybe-closing cache. That does not work: in `ciEnv::register_method`, we already have `SCEntry*` in our hands, and once we acquire the `Compile_lock`, the whole `SCCache` might be gone, `SCEntry*` points to garbage, and we SEGV. This one is easy to solve: check that cache is still on, under the lock.
> 
> 2. For cache reader side, we have a `reading_nmethod` counter, which is supposed to track how many nmethod readers are currently active. Unfortunately, this is still racy: nothing prevents new nmethod readers to appear _"after"_ we closed the cache. So those nmethod readers can access the cache in invalid state. There is also piggybacking on `Compilation_lock`, which AFAICS is for WhiteBox paths! So this is not great. I replaced the whole thing with carefully tracking the nmethod reader counts, and making sure we have the phasing right.
> 
> Eliminating `Compilation_lock` wait improves performance and variance on short workloads as well. Observe:
> 
> 
> $ rm -f app.cds*; taskset -c 0-7 hyperfine -w 50 -r 100 "build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp hellostream.jar HelloStream"
> 
> # BEFORE (this also crashes every so often)
> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp hellostream.jar HelloStream
>   Time (mean ? ?):      24.0 ms ?   4.3 ms    [User: 14.1 ms, System: 9.8 ms]
>   Range (min ? max):    17.0 ms ?  27.3 ms    100 runs
>  
>   Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.
> 
> # AFTER
> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp hellostream....

@iklam, @veresov -- you might want to take a look. This blocks performance testing, because current `-XX:CacheDataStore` tests crash for me here a lot.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/13#issuecomment-2328966708

From ioi.lam at oracle.com  Wed Sep  4 22:04:53 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Wed, 4 Sep 2024 15:04:53 -0700
Subject: RFR: 8329706: Implement -XX:+AOTClassLinking
Message-ID: <0cf74e29-ac52-421f-8b18-beeacf776785@oracle.com>

Hi, this is the 3rd PR for JEP 483 - Ahead-of-Time Class Loading & 
Linking [1]

The PR is https://github.com/openjdk/jdk/pull/20843

The corresponding CSR is https://bugs.openjdk.org/browse/JDK-8339506

The plan [2] is to break down JEP 483 in a series of 7 PRs to make it 
easier to review. I will post the other PRs soon.

Thanks

- Ioi

===

[1] https://openjdk.org/jeps/483
[2] https://bugs.openjdk.org/browse/JDK-8331497


From duke at openjdk.org  Thu Sep  5 05:52:30 2024
From: duke at openjdk.org (duke)
Date: Thu, 5 Sep 2024 05:52:30 GMT
Subject: git: openjdk/leyden: premain: More clean up for upstreaming
 JDK-8329706 Implement -XX:+AOTClassLinking
Message-ID: <183631f9-bd06-4d05-8a61-941c59665fd6@openjdk.org>

Changeset: 242e33d3
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-09-04 22:49:34 +0000
URL:       https://git.openjdk.org/leyden/commit/242e33d3cadaaaf775b9aeca477943de922b8f2d

More clean up for upstreaming JDK-8329706 Implement -XX:+AOTClassLinking

! src/hotspot/share/cds/aotClassLinker.cpp
! src/hotspot/share/cds/aotClassLinker.hpp
! src/hotspot/share/cds/aotConstantPoolResolver.cpp
! src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp
! src/hotspot/share/cds/aotLinkedClassBulkLoader.hpp
! src/hotspot/share/cds/aotLinkedClassTable.cpp
! src/hotspot/share/cds/aotLinkedClassTable.hpp
! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/cds_globals.hpp
! test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java
! test/hotspot/jtreg/runtime/cds/appcds/leyden/LeydenAndOldClasses.java


From shade at openjdk.org  Thu Sep  5 09:10:29 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 5 Sep 2024 09:10:29 GMT
Subject: RFR: Fix SCCache closing races
In-Reply-To: <-Nc5VbDx07wncjS83CruVVwuOUMB7LKnIbyU94Uj3_c=.167a2897-4000-4f16-879d-366085439cb5@github.com>
References: <292kZbD9f1qE0V24gStvcVuraPqxySE8k51sr801ZuM=.67f8ed84-a97e-446d-940e-d9e25294f36a@github.com>
 <-Nc5VbDx07wncjS83CruVVwuOUMB7LKnIbyU94Uj3_c=.167a2897-4000-4f16-879d-366085439cb5@github.com>
Message-ID: <5D_-tdF9S2BnYweHSigOipAQXSvWVS2-91SWDm8iq_E=.67c3f892-4872-49ca-9e21-caeaef02cf30@github.com>

On Wed, 4 Sep 2024 21:38:51 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Please, use [premain] prefix in subjects which we use in JBS for our bugs. And Ioi filed SKARA request to automatically send our PR requests to Leyden-dev mailing list because I missed this PR.

Thanks! I see we do not prefix commit messages with `[premain]` when they do not have the associated JBS entries. So I'll skip this one, and see if we can integrated without JBS entry.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/13#issuecomment-2330998299

From duke at openjdk.org  Thu Sep  5 09:10:30 2024
From: duke at openjdk.org (duke)
Date: Thu, 5 Sep 2024 09:10:30 GMT
Subject: RFR: Fix SCCache closing races
In-Reply-To: <292kZbD9f1qE0V24gStvcVuraPqxySE8k51sr801ZuM=.67f8ed84-a97e-446d-940e-d9e25294f36a@github.com>
References: <292kZbD9f1qE0V24gStvcVuraPqxySE8k51sr801ZuM=.67f8ed84-a97e-446d-940e-d9e25294f36a@github.com>
Message-ID: <hp-lA4lVsuSaxF_VIxtyLv5yfLzA2qTDGaTHIdft188=.588e5f9a-9937-4f46-9cb9-29e0d26b02fc@github.com>

On Wed, 4 Sep 2024 12:46:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have been scratching my head why Leyden builds crash with multiple iterations of `HelloStream` example.
> 
> The crashes are of various shapes, but they have a similar clue: it happens when we touch `SCCache` when it was already closed: `hs_err` shows we have called `before_exit`, `gdb` shows `SCCache::_cache` is already `nullptr`, but the crashes are in compiler code that accesses `SCCache`.
> 
> Looking at `SCCache` closing code, I found two major bugs:
> 
> 1. For cache writer side, we piggyback on `Compile_lock` to abitrate the access to maybe-closing cache. That does not work: in `ciEnv::register_method`, we already have `SCEntry*` in our hands, and once we acquire the `Compile_lock`, the whole `SCCache` might be gone, `SCEntry*` points to garbage, and we SEGV. This one is easy to solve: check that cache is still on, under the lock.
> 
> 2. For cache reader side, we have a `reading_nmethod` counter, which is supposed to track how many nmethod readers are currently active. Unfortunately, this is still racy: nothing prevents new nmethod readers to appear _"after"_ we closed the cache. So those nmethod readers can access the cache in invalid state. There is also piggybacking on `Compilation_lock`, which AFAICS is for WhiteBox paths! So this is not great. I replaced the whole thing with carefully tracking the nmethod reader counts, and making sure we have the phasing right.
> 
> Eliminating `Compilation_lock` wait improves performance and variance on short workloads as well. Observe:
> 
> 
> $ rm -f app.cds*; taskset -c 0-7 hyperfine -w 50 -r 100 "build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp hellostream.jar HelloStream"
> 
> # BEFORE (this also crashes every so often)
> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp hellostream.jar HelloStream
>   Time (mean ? ?):      24.0 ms ?   4.3 ms    [User: 14.1 ms, System: 9.8 ms]
>   Range (min ? max):    17.0 ms ?  27.3 ms    100 runs
>  
>   Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.
> 
> # AFTER
> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp hellostream....

@shipilev 
Your change (at version 36efd4babda0907d59ffa7ab8d15f3c589766110) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/13#issuecomment-2331000260

From mr at openjdk.org  Thu Sep  5 15:03:49 2024
From: mr at openjdk.org (Mark Reinhold)
Date: Thu, 5 Sep 2024 15:03:49 GMT
Subject: git: openjdk/leyden-docs: master: Add jcheck configuration
Message-ID: <5600c6f5-7232-48db-8756-c222f1019940@openjdk.org>

Changeset: 5a0db855
Branch: master
Author:    Mark Reinhold <mr at openjdk.org>
Date:      2024-09-05 11:01:36 +0000
URL:       https://git.openjdk.org/leyden-docs/commit/5a0db85524faf3256e0dede09af604fac3e67922

Add jcheck configuration

+ .jcheck/conf


From kvn at openjdk.org  Thu Sep  5 15:34:11 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 5 Sep 2024 15:34:11 GMT
Subject: git: openjdk/leyden: premain: Fix SCCache closing races
Message-ID: <eb1b790e-3fe8-4971-967b-b194d185bc55@openjdk.org>

Changeset: cf036d70
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-09-05 15:32:30 +0000
URL:       https://git.openjdk.org/leyden/commit/cf036d707b1cecad037b5543a07649a55d59f0e2

Fix SCCache closing races

Reviewed-by: kvn

! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/code/SCCache.hpp


From shade at openjdk.org  Thu Sep  5 15:35:36 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 5 Sep 2024 15:35:36 GMT
Subject: Integrated: Fix SCCache closing races
In-Reply-To: <292kZbD9f1qE0V24gStvcVuraPqxySE8k51sr801ZuM=.67f8ed84-a97e-446d-940e-d9e25294f36a@github.com>
References: <292kZbD9f1qE0V24gStvcVuraPqxySE8k51sr801ZuM=.67f8ed84-a97e-446d-940e-d9e25294f36a@github.com>
Message-ID: <kpu9-RE0_ahdzVeNDHXj8FbNL58FGKS8tnI4l9jl97U=.764ff346-8323-4d6f-917f-d7ba95dae85d@github.com>

On Wed, 4 Sep 2024 12:46:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have been scratching my head why Leyden builds crash with multiple iterations of `HelloStream` example.
> 
> The crashes are of various shapes, but they have a similar clue: it happens when we touch `SCCache` when it was already closed: `hs_err` shows we have called `before_exit`, `gdb` shows `SCCache::_cache` is already `nullptr`, but the crashes are in compiler code that accesses `SCCache`.
> 
> Looking at `SCCache` closing code, I found two major bugs:
> 
> 1. For cache writer side, we piggyback on `Compile_lock` to abitrate the access to maybe-closing cache. That does not work: in `ciEnv::register_method`, we already have `SCEntry*` in our hands, and once we acquire the `Compile_lock`, the whole `SCCache` might be gone, `SCEntry*` points to garbage, and we SEGV. This one is easy to solve: check that cache is still on, under the lock.
> 
> 2. For cache reader side, we have a `reading_nmethod` counter, which is supposed to track how many nmethod readers are currently active. Unfortunately, this is still racy: nothing prevents new nmethod readers to appear _"after"_ we closed the cache. So those nmethod readers can access the cache in invalid state. There is also piggybacking on `Compilation_lock`, which AFAICS is for WhiteBox paths! So this is not great. I replaced the whole thing with carefully tracking the nmethod reader counts, and making sure we have the phasing right.
> 
> Eliminating `Compilation_lock` wait improves performance and variance on short workloads as well. Observe:
> 
> 
> $ rm -f app.cds*; taskset -c 0-7 hyperfine -w 50 -r 100 "build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp hellostream.jar HelloStream"
> 
> # BEFORE (this also crashes every so often)
> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp hellostream.jar HelloStream
>   Time (mean ? ?):      24.0 ms ?   4.3 ms    [User: 14.1 ms, System: 9.8 ms]
>   Range (min ? max):    17.0 ms ?  27.3 ms    100 runs
>  
>   Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.
> 
> # AFTER
> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp hellostream....

This pull request has now been integrated.

Changeset: cf036d70
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/leyden/commit/cf036d707b1cecad037b5543a07649a55d59f0e2
Stats:     101 lines in 3 files changed: 84 ins; 5 del; 12 mod

Fix SCCache closing races

Reviewed-by: kvn

-------------

PR: https://git.openjdk.org/leyden/pull/13

From shade at openjdk.org  Thu Sep  5 17:44:11 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 5 Sep 2024 17:44:11 GMT
Subject: RFR: Mark Leyden tests that require artifacts with "external-dep"
Message-ID: <cVKzHMQ4gidQfPcSmAb5fH7RLWapBqQgWKFLUfBx8Oc=.67021a71-2ea4-4ca0-832a-f2e4c5ba7f0a@github.com>

[JDK-8323717](https://bugs.openjdk.org/browse/JDK-8323717) added a new keyword that marks tests that require external artifacts. This allows skipping the tests that would definitely fail without artifact resolution. This PR marks the new Leyden tests.

Tested with:


$ JTREG_KEYWORDS='!external-dep' CONF=linux-x86_64-server-fastdebug make test TEST=runtime/cds/appcds

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/hotspot/jtreg/runtime/cds/appcds         288   288     0     0   
==============================

-------------

Commit messages:
 - External-dep

Changes: https://git.openjdk.org/leyden/pull/14/files
  Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=14&range=00
  Stats: 16 lines in 4 files changed: 16 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/leyden/pull/14.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/14/head:pull/14

PR: https://git.openjdk.org/leyden/pull/14

From duke at openjdk.org  Thu Sep  5 23:17:14 2024
From: duke at openjdk.org (duke)
Date: Thu, 5 Sep 2024 23:17:14 GMT
Subject: git: openjdk/leyden: hermetic-java-runtime: 60 new changesets
Message-ID: <be95c745-03ff-46da-b340-e1ad60b82dca@openjdk.org>

Changeset: 3a88fd43
Branch: hermetic-java-runtime
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2024-09-03 06:58:29 +0000
URL:       https://git.openjdk.org/leyden/commit/3a88fd437dfb218df5d3338c8ee7d70416839cf8

8334724: C2: remove PhaseIdealLoop::cast_incr_before_loop()

Reviewed-by: chagedorn, kvn

! src/hotspot/share/opto/loopTransform.cpp
! src/hotspot/share/opto/loopnode.hpp
! src/hotspot/share/opto/loopopts.cpp

Changeset: dc4fd896
Branch: hermetic-java-runtime
Author:    Fei Yang <fyang at openjdk.org>
Date:      2024-09-03 06:58:44 +0000
URL:       https://git.openjdk.org/leyden/commit/dc4fd896289db1d2f6f7bbf5795fec533448a48c

8339359: RISC-V: Use auipc explicitly in far_jump and far_call macro assembler routines

Reviewed-by: rehn, luhenry

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

Changeset: 288fa60e
Branch: hermetic-java-runtime
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-09-03 07:56:04 +0000
URL:       https://git.openjdk.org/leyden/commit/288fa60ebee445bb2835f096d144b9c6dea98df6

8338891: HotSpotDiagnosticsMXBean missing @since tag

Reviewed-by: alanb

! src/jdk.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java

Changeset: ed422ed1
Branch: hermetic-java-runtime
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-09-03 07:56:14 +0000
URL:       https://git.openjdk.org/leyden/commit/ed422ed1a3d6cdb733bc878c4173b43eb2dfb3da

8338817: Wrong indent in API docs for java.lang.management.ManagementFactory

Reviewed-by: alanb, dfuchs

! src/java.management/share/classes/java/lang/management/ManagementFactory.java

Changeset: 6f3e3fd0
Branch: hermetic-java-runtime
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2024-09-03 09:27:59 +0000
URL:       https://git.openjdk.org/leyden/commit/6f3e3fd0d4f5e80e3fdbd26be6483c672479802a

8339411: [PPC64] cmpxchgw/h/b doesn't handle external Label

Reviewed-by: lucy, mbaesken

! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp

Changeset: 633fad8e
Branch: hermetic-java-runtime
Author:    Damon Fenacci <dfenacci at openjdk.org>
Date:      2024-09-03 09:45:43 +0000
URL:       https://git.openjdk.org/leyden/commit/633fad8e53109bef52190494a8b171035229d2ac

8326615: C1/C2 don't handle allocation failure properly during initialization (RuntimeStub::new_runtime_stub fatal crash)

Reviewed-by: thartmann, kvn

! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/compiler/compilationPolicy.cpp
! src/hotspot/share/compiler/compilerDefinitions.cpp
! src/hotspot/share/compiler/compilerDefinitions.hpp
! src/hotspot/share/compiler/compilerDefinitions.inline.hpp
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/compiler/codecache/CheckSegmentedCodeCache.java

Changeset: 7a418fc0
Branch: hermetic-java-runtime
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-09-03 10:25:27 +0000
URL:       https://git.openjdk.org/leyden/commit/7a418fc07464fe359a0b45b6d797c65c573770cb

8338967: Improve performance for MemorySegment::fill

Reviewed-by: mcimadamore, psandoz

! src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
+ test/jdk/java/foreign/TestFill.java
+ test/micro/org/openjdk/bench/java/lang/foreign/TestFill.java

Changeset: 8ea6adc6
Branch: hermetic-java-runtime
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-09-03 12:02:49 +0000
URL:       https://git.openjdk.org/leyden/commit/8ea6adc623ca2183046d794eba806065deea916e

8339364: AIX build fails: various unused variable and function warnings

Reviewed-by: mdoerr, clanger, jwaters

! make/modules/java.desktop/lib/AwtLibraries.gmk
! src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c
! src/java.base/unix/native/libjava/TimeZone_md.c
! src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c
! src/java.desktop/unix/native/common/awt/CUPSfuncs.c
! src/java.desktop/unix/native/common/awt/X11Color.c
! src/java.desktop/unix/native/common/awt/fontpath.c
! src/java.desktop/unix/native/common/java2d/x11/X11FontScaler_md.c
! src/java.desktop/unix/native/common/java2d/x11/X11Renderer.c
! src/java.desktop/unix/native/common/java2d/x11/X11SurfaceData.c
! src/java.desktop/unix/native/common/java2d/x11/X11TextRenderer_md.c
! src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c
! src/java.desktop/unix/native/libawt_xawt/awt/multiVis.c
! src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c

Changeset: b94c3deb
Branch: hermetic-java-runtime
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
Date:      2024-09-03 12:05:02 +0000
URL:       https://git.openjdk.org/leyden/commit/b94c3debf5083dbf5bc21ed7794c1656743ab48e

8339401: Optimize ClassFile load and store instructions

Reviewed-by: liach, redestad

! src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java

Changeset: e0c46d58
Branch: hermetic-java-runtime
Author:    Viktor Klang <vklang at openjdk.org>
Date:      2024-09-03 12:55:23 +0000
URL:       https://git.openjdk.org/leyden/commit/e0c46d589b12aa644e12e4a4c9e84e035f7cf98d

8325397: sun/java2d/Disposer/TestDisposerRace.java fails in linux-aarch64

Reviewed-by: alanb

! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java
! test/jdk/sun/java2d/Disposer/TestDisposerRace.java

Changeset: 4ca2c208
Branch: hermetic-java-runtime
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-09-03 13:32:50 +0000
URL:       https://git.openjdk.org/leyden/commit/4ca2c208ea2b308093b4a25b04a274f9b1ec6a1d

8338740: java/net/httpclient/HttpsTunnelAuthTest.java fails with java.io.IOException: HTTP/1.1 header parser received no bytes

Reviewed-by: djelinski, jpai

! test/jdk/java/net/httpclient/ProxyServer.java

Changeset: ad40a122
Branch: hermetic-java-runtime
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-03 13:44:48 +0000
URL:       https://git.openjdk.org/leyden/commit/ad40a122d632d65052b71125c0dfd58c54e3a521

8339214: Remove misleading CodeBuilder.loadConstant(Opcode, ConstantDesc)

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
! src/java.base/share/classes/java/lang/classfile/instruction/ConstantInstruction.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassRemapperImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java
! test/jdk/jdk/classfile/AdaptCodeTest.java
! test/jdk/jdk/classfile/LDCTest.java
! test/jdk/jdk/classfile/OpcodesValidationTest.java
! test/jdk/jdk/classfile/helpers/InstructionModelToCodeBuilder.java

Changeset: 66945e50
Branch: hermetic-java-runtime
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-09-03 15:31:09 +0000
URL:       https://git.openjdk.org/leyden/commit/66945e501049de3a1e1d73303928af87190ae33c

8339336: Fix build system whitespace to adhere to coding conventions

Reviewed-by: erikj

! make/Bundles.gmk
! make/CompileToolsJdk.gmk
! make/CopyInterimTZDB.gmk
! make/Docs.gmk
! make/Global.gmk
! make/Images.gmk
! make/Init.gmk
! make/InitSupport.gmk
! make/JrtfsJar.gmk
! make/Main.gmk
! make/MainSupport.gmk
! make/RunTests.gmk
! make/RunTestsPrebuilt.gmk
! make/RunTestsPrebuiltSpec.gmk
! make/SourceRevision.gmk
! make/StaticLibsImage.gmk
! make/TestImage.gmk
! make/ToolsHotspot.gmk
! make/ToolsJdk.gmk
! make/ZipSecurity.gmk
! make/autoconf/Makefile.template
! make/autoconf/basic.m4
! make/autoconf/basic_tools.m4
! make/autoconf/boot-jdk.m4
! make/autoconf/bootcycle-spec.gmk.template
! make/autoconf/compare.sh.template
! make/autoconf/configure.ac
! make/autoconf/flags-cflags.m4
! make/autoconf/hotspot.m4
! make/autoconf/jdk-options.m4
! make/autoconf/jdk-version.m4
! make/autoconf/jvm-features.m4
! make/autoconf/lib-tests.m4
! make/autoconf/platform.m4
! make/autoconf/spec.gmk.template
! make/autoconf/toolchain.m4
! make/autoconf/util.m4
! make/autoconf/util_paths.m4
! make/common/CopyFiles.gmk
! make/common/Execute.gmk
! make/common/FileUtils.gmk
! make/common/JarArchive.gmk
! make/common/JavaCompilation.gmk
! make/common/JdkNativeCompilation.gmk
! make/common/MakeBase.gmk
! make/common/MakeIO.gmk
! make/common/Modules.gmk
! make/common/NativeCompilation.gmk
! make/common/ProcessMarkdown.gmk
! make/common/TestFilesCompilation.gmk
! make/common/TextFileProcessing.gmk
! make/common/Utils.gmk
! make/common/ZipArchive.gmk
! make/common/native/CompileFile.gmk
! make/devkit/Makefile
! make/devkit/Tools.gmk
! make/hotspot/CopyToExplodedJdk.gmk
! make/hotspot/lib/CompileGtest.gmk
! make/hotspot/lib/CompileJvm.gmk
! make/hotspot/lib/JvmOverrideFiles.gmk
! make/ide/eclipse/CreateWorkspace.gmk
! make/ide/idea/jdk/idea.gmk
! make/ide/visualstudio/hotspot/CreateVSProject.gmk
! make/ide/vscode/hotspot/CreateVSCodeProject.gmk
! make/modules/java.base/Copy.gmk
! make/modules/java.base/Lib.gmk
! make/modules/java.base/gensrc/GensrcBuffer.gmk
! make/modules/java.base/gensrc/GensrcExceptions.gmk
! make/modules/java.base/gensrc/GensrcMisc.gmk
! make/modules/java.base/gensrc/GensrcModuleLoaderMap.gmk
! make/modules/java.base/lib/CoreLibraries.gmk
! make/modules/java.desktop/lib/AwtLibraries.gmk
! make/modules/java.desktop/lib/ClientLibraries.gmk
! make/modules/java.management/Lib.gmk
! make/modules/jdk.javadoc/Gensrc.gmk
! make/modules/jdk.jdeps/Gensrc.gmk
! make/modules/jdk.jlink/Launcher.gmk
! make/modules/jdk.management/Lib.gmk
! make/test/BuildMicrobenchmark.gmk
! make/test/JtregNativeHotspot.gmk
! make/test/JtregNativeJdk.gmk

Changeset: c3adcb84
Branch: hermetic-java-runtime
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-09-03 15:31:19 +0000
URL:       https://git.openjdk.org/leyden/commit/c3adcb843953b599b3c93d6b51afcc709ceaf45b

8338916: Build warnings about overriding recipe for jvm-ldflags.txt

Reviewed-by: jwaters, erikj

! make/common/NativeCompilation.gmk
! make/common/native/Link.gmk

Changeset: 0d593cd1
Branch: hermetic-java-runtime
Author:    Amit Kumar <amitkumar at openjdk.org>
Date:      2024-09-03 15:32:42 +0000
URL:       https://git.openjdk.org/leyden/commit/0d593cd1945e93a7d3c33ad270a81403b6fbeb3f

8339419: [s390x] Problemlist compiler/c2/irTests/TestIfMinMax.java

Reviewed-by: thartmann

! test/hotspot/jtreg/ProblemList.txt

Changeset: cfec3ac9
Branch: hermetic-java-runtime
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2024-09-03 19:01:58 +0000
URL:       https://git.openjdk.org/leyden/commit/cfec3ac911a5a947cdb8c516d0a4b8097f0cc1dd

8337317: serviceability/jvmti tests failed with FATAL ERROR in native method: Failed during the GetClassSignature call

Reviewed-by: lmesnik, sspitsyn, cjplummer

! test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp
! test/hotspot/jtreg/serviceability/jvmti/VMObjectAlloc/libVMObjectAlloc.cpp

Changeset: 130ac13c
Branch: hermetic-java-runtime
Author:    Doug Simon <dnsimon at openjdk.org>
Date:      2024-09-03 19:04:04 +0000
URL:       https://git.openjdk.org/leyden/commit/130ac13cb9c2dede4ceede4ad6c3c820fdea2fe3

8337265: Test static-libs build in GitHub Actions

Reviewed-by: erikj, ihse

! .github/actions/upload-bundles/action.yml
! .github/workflows/build-linux.yml

Changeset: 5ebdf2d2
Branch: hermetic-java-runtime
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-09-03 19:06:00 +0000
URL:       https://git.openjdk.org/leyden/commit/5ebdf2d2720b82c4e9783fc6a9aa58344d5e2f2a

8338708: Don't create/destroy debug agent cmdQueueLock for each connection

Reviewed-by: amenkov, lmesnik

! src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c
+ test/jdk/com/sun/jdi/ReattachStressTest.java

Changeset: a7120e2b
Branch: hermetic-java-runtime
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2024-09-03 19:06:10 +0000
URL:       https://git.openjdk.org/leyden/commit/a7120e2b251e1337df5bd4a2808638d28b7d3bd3

8311993: Test serviceability/sa/UniqueVtableTest.java failed: duplicate vtables detected

Reviewed-by: cjplummer, kevinw, dholmes

! src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp

Changeset: a22e932a
Branch: hermetic-java-runtime
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-09-03 19:51:12 +0000
URL:       https://git.openjdk.org/leyden/commit/a22e932ab838762a013fc25b8061165be93feeb3

8337163: Improve SA error message when failing to attach to a core file

Reviewed-by: amenkov, kevinw

! src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.cpp
! src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m

Changeset: bbb51616
Branch: hermetic-java-runtime
Author:    Mark Powers <mpowers at openjdk.org>
Date:      2024-09-03 19:55:58 +0000
URL:       https://git.openjdk.org/leyden/commit/bbb516163d400a9c7e923e423fe2a60091b59322

8337664: Distrust TLS server certificates issued after Oct 2024 and anchored by Entrust Root CAs

Reviewed-by: mullan, rhalade

! src/java.base/share/classes/sun/security/validator/CADistrustPolicy.java
+ src/java.base/share/classes/sun/security/validator/EntrustTLSPolicy.java
! src/java.base/share/conf/security/java.security
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/Distrust.java
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/affirmtrustcommercialca-chain.pem
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/affirmtrustnetworkingca-chain.pem
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/affirmtrustpremiumca-chain.pem
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/affirmtrustpremiumeccca-chain.pem
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/entrust2048ca-chain.pem
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/entrustevca-chain.pem
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/entrustrootcaec1-chain.pem
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/entrustrootcag2-chain.pem
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/entrustrootcag4-chain.pem

Changeset: 90f3f432
Branch: hermetic-java-runtime
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-09-04 03:41:42 +0000
URL:       https://git.openjdk.org/leyden/commit/90f3f4325772773f1dc1814c56d7326d5389e2c7

8328877: [JNI] The JNI Specification needs to address the limitations of integer UTF-8 String lengths

Reviewed-by: cjplummer, alanb

! src/hotspot/os/posix/dtrace/hotspot_jni.d
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jniCheck.cpp
! src/hotspot/share/runtime/threads.cpp
! src/hotspot/share/utilities/dtrace_disabled.hpp
! src/java.base/share/native/include/jni.h
! test/hotspot/jtreg/native_sanity/JniVersion.java
+ test/hotspot/jtreg/runtime/jni/checked/TestLargeUTF8Length.java
+ test/hotspot/jtreg/runtime/jni/checked/libTestLargeUTF8Length.c

Changeset: 5998f4b6
Branch: hermetic-java-runtime
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Date:      2024-09-04 04:26:55 +0000
URL:       https://git.openjdk.org/leyden/commit/5998f4b6f53769f98188ae8c23ea49cc1f7aa802

8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed

Reviewed-by: tr, aivanov, aturbanov

! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java

Changeset: 9a1024de
Branch: hermetic-java-runtime
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-04 05:05:20 +0000
URL:       https://git.openjdk.org/leyden/commit/9a1024dec68057c7c581ac0a38fc7f96489a0a76

8190329: [macos] Swing InterOp Platform.exit() crash

Co-authored-by: Kevin Rushforth <kcr at openjdk.org>
Reviewed-by: kcr, azvegint

! src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m
! src/java.desktop/macosx/native/libosxapp/ThreadUtilities.h
! src/java.desktop/macosx/native/libosxapp/ThreadUtilities.m

Changeset: f2c992c5
Branch: hermetic-java-runtime
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-09-04 07:09:59 +0000
URL:       https://git.openjdk.org/leyden/commit/f2c992c5af021ab0ff8429fd261314bc7e01f7df

8339300: CollectorPolicy.young_scaled_initial_ergo_vm gtest fails on ppc64 based platforms

Reviewed-by: mdoerr, lucy

! test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp

Changeset: a6186051
Branch: hermetic-java-runtime
Author:    Joel Sikstr?m <joel.sikstrom at oracle.com>
Committer: Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-04 08:56:02 +0000
URL:       https://git.openjdk.org/leyden/commit/a61860511f67038962c54e114599948ca103dae8

8339399: ZGC: Remove unnecessary page reset when splitting pages

Reviewed-by: stefank, eosterlund, aboldtch

! src/hotspot/share/gc/z/zPage.cpp
! src/hotspot/share/gc/z/zPage.hpp

Changeset: 7ad61605
Branch: hermetic-java-runtime
Author:    Joel Sikstr?m <joel.sikstrom at oracle.com>
Committer: Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-04 09:09:15 +0000
URL:       https://git.openjdk.org/leyden/commit/7ad61605f1669f51a97f4f263a7afaa9ab7706be

8339163: ZGC: Race in clearing of remembered sets

Reviewed-by: stefank, eosterlund, aboldtch

! src/hotspot/share/gc/z/zRemembered.cpp
! src/hotspot/share/gc/z/zRemembered.hpp

Changeset: 4e2dde2f
Branch: hermetic-java-runtime
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-09-04 10:35:04 +0000
URL:       https://git.openjdk.org/leyden/commit/4e2dde2f0d6f96d5f07020d2417189f411c4596a

8339371: jlink.log warning when building after JDK-8338404

Reviewed-by: erikj, alanb

! make/InterimImage.gmk

Changeset: e25a9e7f
Branch: hermetic-java-runtime
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-09-04 12:08:16 +0000
URL:       https://git.openjdk.org/leyden/commit/e25a9e7fd86e4eaf020e54021efaa7059dc654c9

8339486: JFR: Modernize

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/query/Function.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/util/StopWatch.java
! test/jdk/jdk/jfr/api/event/TestGetDuration.java
! test/jdk/jdk/jfr/api/recording/misc/TestGetStream.java
! test/jdk/jdk/jfr/api/recording/options/TestDuration.java
! test/jdk/jdk/jfr/api/recording/state/TestStateDuration.java
! test/jdk/jdk/jfr/api/recording/state/TestStateScheduleStart.java
! test/jdk/jdk/jfr/event/runtime/TestThreadCpuTimeEvent.java

Changeset: bd8569bc
Branch: hermetic-java-runtime
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-04 12:29:40 +0000
URL:       https://git.openjdk.org/leyden/commit/bd8569bc6cc888cbf514e9329e2c24a059d89711

8339131: Remove rarely-used accessor methods from Opcode

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
! src/java.base/share/classes/java/lang/classfile/Opcode.java
! src/java.base/share/classes/java/lang/classfile/instruction/ConstantInstruction.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BlockCodeBuilderImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java
! src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java

Changeset: c7d15f1f
Branch: hermetic-java-runtime
Author:    Attila Szegedi <attila at openjdk.org>
Date:      2024-09-04 13:40:40 +0000
URL:       https://git.openjdk.org/leyden/commit/c7d15f1fe09e61c1e61ee253e7e3df4c2b9306a1

8325679: Optimize ArrayList subList sort

Reviewed-by: liach

! src/java.base/share/classes/java/util/ArrayList.java
! test/jdk/java/util/List/ListDefaults.java

Changeset: 6f8714ee
Branch: hermetic-java-runtime
Author:    Jasmine Karthikeyan <jkarthikeyan at openjdk.org>
Date:      2024-09-04 13:44:24 +0000
URL:       https://git.openjdk.org/leyden/commit/6f8714ee197eb48923209299fd842f6757f0a945

8336860: x86: Change integer src operand for CMoveL of 0 and 1 to long

Reviewed-by: epeter, chagedorn, shade, qamai, jbhateja

! src/hotspot/cpu/x86/x86_64.ad
+ test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java
! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java
! test/micro/org/openjdk/bench/vm/compiler/x86/BasicRules.java

Changeset: 0cfd08f5
Branch: hermetic-java-runtime
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-09-04 15:48:32 +0000
URL:       https://git.openjdk.org/leyden/commit/0cfd08f55aa166dc3f027887c886fa0b40a2ca21

8339112: Move JVM Klass flags out of AccessFlags

Reviewed-by: matsaave, cjplummer, dlong, thartmann, yzheng

! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp
! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
! src/hotspot/cpu/arm/c1_Runtime1_arm.cpp
! src/hotspot/cpu/arm/c2_MacroAssembler_arm.cpp
! src/hotspot/cpu/arm/interp_masm_arm.cpp
! src/hotspot/cpu/arm/templateTable_arm.cpp
! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/c1_Runtime1_ppc.cpp
! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
! src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/c1_Runtime1_riscv.cpp
! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/interp_masm_riscv.cpp
! src/hotspot/cpu/riscv/templateTable_riscv.cpp
! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
! src/hotspot/cpu/s390/c1_Runtime1_s390.cpp
! src/hotspot/cpu/s390/interp_masm_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.cpp
! src/hotspot/cpu/s390/templateTable_s390.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/interp_masm_x86.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/share/ci/ciInstanceKlass.cpp
! src/hotspot/share/ci/ciKlass.cpp
! src/hotspot/share/ci/ciKlass.hpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/oops/klass.hpp
! src/hotspot/share/oops/klass.inline.hpp
+ src/hotspot/share/oops/klassFlags.cpp
+ src/hotspot/share/oops/klassFlags.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/library_call.hpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/hotspot/share/utilities/accessFlags.hpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/AccessFlags.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Klass.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfig.java

Changeset: 12d060a2
Branch: hermetic-java-runtime
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2024-09-04 16:21:19 +0000
URL:       https://git.openjdk.org/leyden/commit/12d060a255b9b783488714c6c2cb73a899d3f708

8339148: Make os::Linux::active_processor_count() public

Reviewed-by: dholmes, jwaters

! src/hotspot/os/linux/os_linux.hpp

Changeset: ef96a7b0
Branch: hermetic-java-runtime
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-09-04 16:37:17 +0000
URL:       https://git.openjdk.org/leyden/commit/ef96a7b014795f366af3a90ef8f474cfb621197f

8332901: Select{Current,New}ItemTest.java for Choice don't open popup on macOS

Move SelectCurrentItemTest.java to java/awt/Choice/SelectItem/.
Move SelectNewItemTest.java to java/awt/Choice/SelectItem/.
Use latches to control test flow instead of delays.
Encapsulate the common logic in SelectCurrentItemTest.
Provide overridable checkXXX() methods to modify conditions.
Provide an overridable method which defines where to click
in the choice popup to select an item.

Reviewed-by: honkar, prr, dnguyen

! test/jdk/ProblemList.txt
- test/jdk/java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java
+ test/jdk/java/awt/Choice/SelectItem/SelectCurrentItemTest.java
+ test/jdk/java/awt/Choice/SelectItem/SelectNewItemTest.java
- test/jdk/java/awt/Choice/SelectNewItemTest/SelectNewItemTest.java

Changeset: 433f6d8a
Branch: hermetic-java-runtime
Author:    David M. Lloyd <david.lloyd at redhat.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-09-04 16:46:44 +0000
URL:       https://git.openjdk.org/leyden/commit/433f6d8a0643b59663bf76c0f3a2af27a6cc56b7

8339492: StackMapDecoder::writeFrames makes lots of allocations

Reviewed-by: liach, redestad, jwaters, asotona

! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java

Changeset: 1353601d
Branch: hermetic-java-runtime
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-09-04 17:25:37 +0000
URL:       https://git.openjdk.org/leyden/commit/1353601dcc8f9ec3e12dea21dc61b3585a154b13

8338924: C1: assert(0 <= i && i < _len) failed: illegal index 5 for length 5

Co-authored-by: Dean Long <dlong at openjdk.org>
Reviewed-by: kvn, thartmann

! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/compiler/methodLiveness.cpp
! test/hotspot/jtreg/ProblemList-Xcomp.txt
! test/hotspot/jtreg/runtime/interpreter/LastJsrTest.java

Changeset: b8d560b6
Branch: hermetic-java-runtime
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Harshitha Onkar <honkar at openjdk.org>
Date:      2024-09-04 20:05:27 +0000
URL:       https://git.openjdk.org/leyden/commit/b8d560b6cd9ea35c747487017107a6caeacf8a98

8339233: Test javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java#id failed: Button renderings are different after window resize

Reviewed-by: honkar

! test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java

Changeset: d4dfa012
Branch: hermetic-java-runtime
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-09-04 20:49:32 +0000
URL:       https://git.openjdk.org/leyden/commit/d4dfa0127f4d51c8127c5d4dfe3b58c09500e80f

8338530: CDS warning Skipping java/lang/invoke/BoundMethodHandle$Species_LLLL

Reviewed-by: iklam, ccheung

! src/hotspot/share/classfile/systemDictionaryShared.cpp
! test/hotspot/jtreg/runtime/cds/appcds/jvmti/dumpingWithAgent/DumpingWithJavaAgent.java

Changeset: 55312e15
Branch: hermetic-java-runtime
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-09-04 22:45:17 +0000
URL:       https://git.openjdk.org/leyden/commit/55312e1549c36be46b0f3b3b40763a33311c3e25

8338937: Optimize the string concatenation of ClassDesc

Reviewed-by: liach

! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/StringConcatHelper.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/constant/ClassDesc.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java

Changeset: 96df5a6d
Branch: hermetic-java-runtime
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-09-04 23:58:17 +0000
URL:       https://git.openjdk.org/leyden/commit/96df5a6d8f90c988b354dbe6bdc510aa4b8ee98b

8339316: Test runtime/exceptionMsgs/NoClassDefFoundError/NoClassDefFoundErrorTest.java fails after  JDK-8338257

Reviewed-by: jsjolen, coleenp

! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/prims/jniCheck.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/utilities/exceptions.cpp
! test/hotspot/jtreg/ProblemList.txt

Changeset: 28de44da
Branch: hermetic-java-runtime
Author:    Amit Kumar <amitkumar at openjdk.org>
Date:      2024-09-05 07:01:29 +0000
URL:       https://git.openjdk.org/leyden/commit/28de44da71871bec7648f01a4df2faee43fa43b6

8332461: ubsan : dependencies.cpp:906:3: runtime error: load of value 4294967295, which is not a valid value for type 'DepType'

Reviewed-by: stefank, kvn, dlong

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

Changeset: 96a0502d
Branch: hermetic-java-runtime
Author:    Ivan Walulya <iwalulya at openjdk.org>
Date:      2024-09-05 08:18:35 +0000
URL:       https://git.openjdk.org/leyden/commit/96a0502d624e3eff1b00a7c63e8b3a27870b475e

8339369: G1: TestVerificationInConcurrentCycle.java fails with "Missing rem set entry" when using "-XX:G1RSetUpdatingPauseTimePercent=0 -XX:G1UpdateBufferSize=2"

Reviewed-by: tschatzl, kbarrett

! src/hotspot/share/gc/g1/g1FullCollector.cpp
! src/hotspot/share/gc/g1/g1FullGCResetMetadataTask.cpp

Changeset: 2305d18e
Branch: hermetic-java-runtime
Author:    Yagmur Eren <yagmur.eren at oracle.com>
Date:      2024-09-05 09:26:08 +0000
URL:       https://git.openjdk.org/leyden/commit/2305d18e8d53dbbf341b580b60f9ed21f408bff1

8339384: Unintentional IOException in jdk.jdi module when JDWP end of stream occurs

Reviewed-by: cjplummer, kevinw

! src/jdk.jdi/share/classes/com/sun/tools/jdi/TargetVM.java

Changeset: 340e131d
Branch: hermetic-java-runtime
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-09-05 10:52:44 +0000
URL:       https://git.openjdk.org/leyden/commit/340e131d616bd81ccd0bdc3817aead0284014cac

8338971: IGV: Add incrementally inlined method name to phase name

Reviewed-by: rcastanedalo, kvn

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

Changeset: cb9f5c57
Branch: hermetic-java-runtime
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
Date:      2024-09-05 11:45:49 +0000
URL:       https://git.openjdk.org/leyden/commit/cb9f5c5791d17afbf72f7debe8013b77e45b3b56

8339290: Optimize ClassFile Utf8EntryImpl#writeTo

Reviewed-by: redestad, liach

! src/java.base/share/classes/java/lang/StringCoding.java
! 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/classfile/impl/AbstractPoolEntry.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java
+ test/jdk/java/lang/String/CountNonZeroAscii.java
+ test/micro/org/openjdk/bench/java/lang/classfile/Utf8EntryWriteTo.java

Changeset: 6be92726
Branch: hermetic-java-runtime
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-09-05 13:10:24 +0000
URL:       https://git.openjdk.org/leyden/commit/6be927260a84b1d7542167e526ff41f7dc26cab0

8338591: Improve performance of MemorySegment::copy

Reviewed-by: mcimadamore

! src/java.base/share/classes/java/lang/foreign/MemorySegment.java
! src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
! test/jdk/java/foreign/TestSegmentCopy.java
+ test/micro/org/openjdk/bench/java/lang/foreign/CopyTest.java

Changeset: a505a1dd
Branch: hermetic-java-runtime
Author:    Fernando Guallini <fguallini at openjdk.org>
Committer: Sean Mullan <mullan at openjdk.org>
Date:      2024-09-05 13:14:00 +0000
URL:       https://git.openjdk.org/leyden/commit/a505a1dda3bc6975bb11f390543b38618ddf2626

8337951: Test sun/security/validator/samedn.sh CertificateNotYetValidException: NotBefore validation

Reviewed-by: mullan

! test/jdk/sun/security/validator/samedn.sh

Changeset: ab656c3a
Branch: hermetic-java-runtime
Author:    Joel Sikstr?m <joel.sikstrom at oracle.com>
Committer: Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-05 13:39:56 +0000
URL:       https://git.openjdk.org/leyden/commit/ab656c3aab8157ed8e70bc126881cbadc825de93

8339579: ZGC: Race results in only one of two remembered sets being cleared

Reviewed-by: stefank, sjohanss

! src/hotspot/share/gc/z/zRememberedSet.cpp

Changeset: b389bb45
Branch: hermetic-java-runtime
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-05 13:49:17 +0000
URL:       https://git.openjdk.org/leyden/commit/b389bb456726184e4691777b1bb02d4b8a8a3f97

8339540: Unify include requirements for PlatformMonitor/Mutex constructors/destructors

Reviewed-by: coleenp, sjohanss

! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/os/windows/os_windows.inline.hpp

Changeset: 042053c3
Branch: hermetic-java-runtime
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-09-05 15:03:54 +0000
URL:       https://git.openjdk.org/leyden/commit/042053c3a82e9fbd4c6866efe872c1c92714e6e7

8003887: File.getCanonicalFile() does not resolve symlinks on MS Windows

Reviewed-by: alanb

! src/java.base/windows/classes/java/io/WinNTFileSystem.java
! src/java.base/windows/native/libjava/WinNTFileSystem_md.c
! test/jdk/java/io/File/GetCanonicalPath.java

Changeset: 4ffcf894
Branch: hermetic-java-runtime
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2024-09-05 15:12:27 +0000
URL:       https://git.openjdk.org/leyden/commit/4ffcf894b5937d6c6914b8f24caead87bd3e4228

8339619: ProblemList runtime/cds/appcds/jvmti/dumpingWithAgent/DumpingWithJavaAgent.java

Reviewed-by: azvegint

! test/hotspot/jtreg/ProblemList.txt

Changeset: 59c4649b
Branch: hermetic-java-runtime
Author:    Artur Barashev <artur.barashev at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
Date:      2024-09-05 15:34:26 +0000
URL:       https://git.openjdk.org/leyden/commit/59c4649be37a387efaf100f368b3e9db06d44f3a

8329959: Update DigestMD5Client.java - fix typo in javadoc string

Reviewed-by: weijun

! src/java.security.sasl/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java

Changeset: b895d7cf
Branch: hermetic-java-runtime
Author:    Suchismith Roy <sroy at openjdk.org>
Committer: Martin Doerr <mdoerr at openjdk.org>
Date:      2024-09-05 15:44:57 +0000
URL:       https://git.openjdk.org/leyden/commit/b895d7cf9fe0370a919e7092e40ac3458d91e95e

8332423: [PPC64] Remove C1_MacroAssembler::call_c_with_frame_resize

Reviewed-by: mdoerr, varadam

! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp
! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.hpp
! src/hotspot/cpu/ppc/c1_Runtime1_ppc.cpp
! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp
! src/hotspot/cpu/ppc/runtime_ppc.cpp
! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp

Changeset: 98020e47
Branch: hermetic-java-runtime
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2024-09-05 15:46:38 +0000
URL:       https://git.openjdk.org/leyden/commit/98020e47996c0c6870e406bd513c8f503a336a73

8338133: Cleanup direct use of `new HtmlTree`

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlLinkFactory.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexRedirectWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SearchWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerialFieldWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerialMethodWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TableOfContents.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Head.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/SnippetTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlTree.java
! test/langtools/jdk/javadoc/doclet/testHtmlDocument/TestHtmlDocument.java
! test/langtools/jdk/javadoc/doclet/testVoidHtmlElements/TestVoidHtmlElements.java

Changeset: e203df46
Branch: hermetic-java-runtime
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2024-09-05 15:51:27 +0000
URL:       https://git.openjdk.org/leyden/commit/e203df46faf610e35e2c2510271ad68199f4fa3f

8338100: C2: assert(!n_loop->is_member(get_loop(lca))) failed: control must not be back in the loop

Co-authored-by: Emanuel Peter <epeter at openjdk.org>
Reviewed-by: chagedorn, thartmann

! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/loopnode.hpp
! src/hotspot/share/opto/parse1.cpp
+ test/hotspot/jtreg/compiler/loopopts/LongCountedLoopInInfiniteLoop.jasm
+ test/hotspot/jtreg/compiler/loopopts/MoveStoreAfterInfiniteLoop.jasm
+ test/hotspot/jtreg/compiler/loopopts/TestLongCountedLoopInInfiniteLoop.java
+ test/hotspot/jtreg/compiler/loopopts/TestMoveStoreAfterInfiniteLoop.java

Changeset: 48d79431
Branch: hermetic-java-runtime
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-09-05 16:34:39 +0000
URL:       https://git.openjdk.org/leyden/commit/48d79431c95759954f6dd283de78fe9f9fe9370a

8339342: FieldAllocationCount is mostly unused

Reviewed-by: fparain, stuefe, matsaave

! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/classFileParser.hpp

Changeset: 9e1af8cc
Branch: hermetic-java-runtime
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-09-05 18:11:18 +0000
URL:       https://git.openjdk.org/leyden/commit/9e1af8cc7cc9f63453097bd35eb3cf29f945d765

8339285: Test fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames

Reviewed-by: alanb

! src/java.base/aix/native/libnio/MappedMemoryUtils.c
! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
! src/java.base/share/classes/java/nio/MappedMemoryUtils.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/unix/native/libnio/MappedMemoryUtils.c
! src/java.base/windows/native/libnio/MappedMemoryUtils.c
+ test/jdk/java/foreign/TestMappedHandshake.java

Changeset: 8fb8cd85
Branch: hermetic-java-runtime
Author:    Hai-May Chao <hchao at openjdk.org>
Date:      2024-09-05 20:17:52 +0000
URL:       https://git.openjdk.org/leyden/commit/8fb8cd85b7bd2e004329b4968f9564f340002cc1

8339347: keytool -importpass insists prompting the user even if there is no terminal

Reviewed-by: weijun

! src/java.base/share/classes/sun/security/tools/keytool/Main.java
+ test/jdk/sun/security/tools/keytool/TestImportPass.java

Changeset: 7cbccb43
Branch: hermetic-java-runtime
Author:    Jiangli Zhou <jianglizhou at google.com>
Date:      2024-09-05 15:47:14 +0000
URL:       https://git.openjdk.org/leyden/commit/7cbccb436295c3af44bbf94ffd183c27264e2425

Merge branch 'master' into hermetic-java-runtime

! make/Images.gmk
! make/Main.gmk
! make/autoconf/configure.ac
! make/autoconf/spec.gmk.template
! make/modules/java.base/lib/CoreLibraries.gmk
! src/hotspot/share/runtime/threads.cpp
! make/Images.gmk
! make/Main.gmk
! make/autoconf/configure.ac
! make/autoconf/spec.gmk.template
! make/modules/java.base/lib/CoreLibraries.gmk
! src/hotspot/share/runtime/threads.cpp


From shade at openjdk.org  Fri Sep  6 08:56:35 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 6 Sep 2024 08:56:35 GMT
Subject: RFR: Workaround CacheDataStore use with source launcher
Message-ID: <YAyYOvD-NbB0hcUwUF9xCGmHkT0RDNLYXKdHSXRy0nY=.d338e229-985d-47ec-a6be-42ec8060d187@github.com>

I was trying to test the simplest workload that involves javac, and that is source launcher. When I attempt to use source launcher with `-XX:CacheDataStore`, it fails with:


$ rm -f app.cds*; build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC HelloStream.java
[0.001s][warning][cds] optimized module handling/full module graph: disabled due to incompatible property: jdk.module.addmods=ALL-DEFAULT
Error occurred during initialization of VM
CacheDataStore cannot be created because AOTClassLinking is enabled but full module graph is disabled


Source launcher adds `--add-modules=ALL-DEFAULT`:


$ man java
...
       In source-file mode, execution proceeds as follows:

...
       ? The compiled classes are executed in  the  context  of  an  unnamed  module,  as  though  --add-mod?
         ules=ALL-DEFAULT  is  in  effect.  This is in addition to any other --add-module options that may be
         have been specified on the command line.


I think we can work that around specifically for Leyden, and also leave a TODO breadcrumb in the code that we need to figure this out on CDS side. This PR does that workaround. With it, source launcher works with simple examples:


$ build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC  HelloStream.java
Warning: CacheDataStore cannot be used with default source launcher environment, disabling --add-modules=ALL-DEFAULT
hello, world

-------------

Commit messages:
 - Warning message
 - Workaround

Changes: https://git.openjdk.org/leyden/pull/15/files
  Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=15&range=00
  Stats: 14 lines in 2 files changed: 13 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/leyden/pull/15.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/15/head:pull/15

PR: https://git.openjdk.org/leyden/pull/15

From shade at openjdk.org  Fri Sep  6 08:59:54 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 6 Sep 2024 08:59:54 GMT
Subject: RFR: Workaround CacheDataStore use with source launcher [v2]
In-Reply-To: <YAyYOvD-NbB0hcUwUF9xCGmHkT0RDNLYXKdHSXRy0nY=.d338e229-985d-47ec-a6be-42ec8060d187@github.com>
References: <YAyYOvD-NbB0hcUwUF9xCGmHkT0RDNLYXKdHSXRy0nY=.d338e229-985d-47ec-a6be-42ec8060d187@github.com>
Message-ID: <WrCeEeFVm7bxm4NUhgdyT37ps3yEIqi81CM7UH86Ft4=.b0e35ac9-debe-4964-8ae0-c1b12cce5e34@github.com>

> I was trying to test the simplest workload that involves javac, and that is source launcher. When I attempt to use source launcher with `-XX:CacheDataStore`, it fails with:
> 
> 
> $ rm -f app.cds*; build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC HelloStream.java
> [0.001s][warning][cds] optimized module handling/full module graph: disabled due to incompatible property: jdk.module.addmods=ALL-DEFAULT
> Error occurred during initialization of VM
> CacheDataStore cannot be created because AOTClassLinking is enabled but full module graph is disabled
> 
> 
> Source launcher adds `--add-modules=ALL-DEFAULT`:
> 
> 
> $ man java
> ...
>        In source-file mode, execution proceeds as follows:
> 
> ...
>        ? The compiled classes are executed in  the  context  of  an  unnamed  module,  as  though  --add-mod?
>          ules=ALL-DEFAULT  is  in  effect.  This is in addition to any other --add-module options that may be
>          have been specified on the command line.
> 
> 
> I think we can work that around specifically for Leyden, and also leave a TODO breadcrumb in the code that we need to figure this out on CDS side. This PR does that workaround. With it, source launcher works with simple examples:
> 
> 
> $ build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC  HelloStream.java
> Warning: CacheDataStore cannot be used with default source launcher environment, disabling --add-modules=ALL-DEFAULT
> hello, world

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Indenting

-------------

Changes:
  - all: https://git.openjdk.org/leyden/pull/15/files
  - new: https://git.openjdk.org/leyden/pull/15/files/5c198f7d..4e490f86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=leyden&pr=15&range=01
 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=15&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/leyden/pull/15.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/15/head:pull/15

PR: https://git.openjdk.org/leyden/pull/15

From heidinga at openjdk.org  Fri Sep  6 12:49:25 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 6 Sep 2024 12:49:25 GMT
Subject: git: openjdk/leyden-docs: master: Update JVMLS talk links and add
 JVMLS 2024
Message-ID: <71f93c06-9eb4-4b37-84b3-92dade63c5cb@openjdk.org>

Changeset: f6e3a877
Branch: master
Author:    Dan Heidinga <heidinga at openjdk.org>
Date:      2024-09-06 12:47:05 +0000
URL:       https://git.openjdk.org/leyden-docs/commit/f6e3a8773d80e17f09b81258ee34dcda6a6c7caf

Update JVMLS talk links and add JVMLS 2024

Reviewed-by: mr

! site/_index.md


From heidinga at openjdk.org  Fri Sep  6 14:11:55 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 6 Sep 2024 14:11:55 GMT
Subject: RFR: Publish: Thoughts on Training Runs
Message-ID: <SQm-Q9Wyohx-EP66GZ1olDfRE-wOY_qUTwm431D3qg8=.4360c8bb-7fa3-4fe4-8014-65090796a009@github.com>

Publish the writeup on training runs

-------------

Commit messages:
 - Fix date tag
 - Tweak formatting
 - Initial writeup of the team's discussions on training runs

Changes: https://git.openjdk.org/leyden-docs/pull/3/files
  Webrev: https://webrevs.openjdk.org/?repo=leyden-docs&pr=3&range=00
  Stats: 131 lines in 1 file changed: 131 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/leyden-docs/pull/3.diff
  Fetch: git fetch https://git.openjdk.org/leyden-docs.git pull/3/head:pull/3

PR: https://git.openjdk.org/leyden-docs/pull/3

From mr at openjdk.org  Fri Sep  6 14:11:56 2024
From: mr at openjdk.org (Mark Reinhold)
Date: Fri, 6 Sep 2024 14:11:56 GMT
Subject: RFR: Publish: Thoughts on Training Runs
In-Reply-To: <SQm-Q9Wyohx-EP66GZ1olDfRE-wOY_qUTwm431D3qg8=.4360c8bb-7fa3-4fe4-8014-65090796a009@github.com>
References: <SQm-Q9Wyohx-EP66GZ1olDfRE-wOY_qUTwm431D3qg8=.4360c8bb-7fa3-4fe4-8014-65090796a009@github.com>
Message-ID: <79zDb8RuJY4AliPiQH2jN-pvGvKmieHznxOkzS038PM=.27a11b03-1357-41cb-bb2e-40c384cb5aca@github.com>

On Wed, 4 Sep 2024 20:24:01 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

> Publish the writeup on training runs

Marked as reviewed by mr (Lead).

Oops, it looks like you opened this PR and the other open PR against openjdk:master. I think you meant leyden-docs:master?

-------------

PR Review: https://git.openjdk.org/leyden-docs/pull/3#pullrequestreview-2283442711
PR Comment: https://git.openjdk.org/leyden-docs/pull/3#issuecomment-2331979770

From heidinga at openjdk.org  Fri Sep  6 14:11:56 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 6 Sep 2024 14:11:56 GMT
Subject: RFR: Publish: Thoughts on Training Runs
In-Reply-To: <SQm-Q9Wyohx-EP66GZ1olDfRE-wOY_qUTwm431D3qg8=.4360c8bb-7fa3-4fe4-8014-65090796a009@github.com>
References: <SQm-Q9Wyohx-EP66GZ1olDfRE-wOY_qUTwm431D3qg8=.4360c8bb-7fa3-4fe4-8014-65090796a009@github.com>
Message-ID: <HrgDVt7g7UPbehO5_FclMl0q4dVChMBSj_uHSZpJog4=.200fd900-7dae-461c-8700-e0b697762335@github.com>

On Wed, 4 Sep 2024 20:24:01 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

> Publish the writeup on training runs

I think this might be a GitHub ui issue - the text says "merge 3 commits into `openjdk:master`" but when I hover on it, it actually links to https://github.com/openjdk/leyden-docs/tree/master

-------------

PR Comment: https://git.openjdk.org/leyden-docs/pull/3#issuecomment-2331999510

From heidinga at openjdk.org  Fri Sep  6 14:12:12 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 6 Sep 2024 14:12:12 GMT
Subject: Integrated: Update JVMLS talk links and add JVMLS 2024
Message-ID: <aWtByfTyI9W6ntUUFIxpco8LZz_ySxlzgZI2yizKGgs=.373798e4-61ba-4679-aa0f-b236a9fa8037@github.com>

Update links and add JVMLS 2024 talk

-------------

Commit messages:
 - Add JVMLS 24 talk link.  Fix JVMLS 23 link

Changes: https://git.openjdk.org/leyden-docs/pull/1/files
  Webrev: https://webrevs.openjdk.org/?repo=leyden-docs&pr=1&range=00
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/leyden-docs/pull/1.diff
  Fetch: git fetch https://git.openjdk.org/leyden-docs.git pull/1/head:pull/1

PR: https://git.openjdk.org/leyden-docs/pull/1

From mr at openjdk.org  Fri Sep  6 14:11:58 2024
From: mr at openjdk.org (Mark Reinhold)
Date: Fri, 6 Sep 2024 14:11:58 GMT
Subject: RFR: Publish: Thoughts on Training Runs
In-Reply-To: <HrgDVt7g7UPbehO5_FclMl0q4dVChMBSj_uHSZpJog4=.200fd900-7dae-461c-8700-e0b697762335@github.com>
References: <SQm-Q9Wyohx-EP66GZ1olDfRE-wOY_qUTwm431D3qg8=.4360c8bb-7fa3-4fe4-8014-65090796a009@github.com>
 <HrgDVt7g7UPbehO5_FclMl0q4dVChMBSj_uHSZpJog4=.200fd900-7dae-461c-8700-e0b697762335@github.com>
Message-ID: <GtO7AYBF6ofVDB0H_e8DrFvWCgg6ml0CBu5yCfKOKD8=.5c54b509-6e68-4cd9-b623-f6ba9f145444@github.com>

On Thu, 5 Sep 2024 15:22:06 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

> I think this might be a GitHub ui issue - the text says "merge 3 commits into `openjdk:master`" but when I hover on it, it actually links to https://github.com/openjdk/leyden-docs/tree/master

Well ... that?s awfully confusing!

-------------

PR Comment: https://git.openjdk.org/leyden-docs/pull/3#issuecomment-2332016292

From mr at openjdk.org  Fri Sep  6 14:12:12 2024
From: mr at openjdk.org (Mark Reinhold)
Date: Fri, 6 Sep 2024 14:12:12 GMT
Subject: Integrated: Update JVMLS talk links and add JVMLS 2024
In-Reply-To: <aWtByfTyI9W6ntUUFIxpco8LZz_ySxlzgZI2yizKGgs=.373798e4-61ba-4679-aa0f-b236a9fa8037@github.com>
References: <aWtByfTyI9W6ntUUFIxpco8LZz_ySxlzgZI2yizKGgs=.373798e4-61ba-4679-aa0f-b236a9fa8037@github.com>
Message-ID: <xeacnJnm1Z51JyqFDKdQVAuVQP4jXSVx-pDEYC91z3A=.6a2cb50f-eca1-401f-aef9-88661f41e901@github.com>

On Wed, 4 Sep 2024 16:25:42 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

> Update links and add JVMLS 2024 talk

Marked as reviewed by mr (Lead).

The change itself looks good, but in the commit message title, s/JVMS/JVMLS/g.

-------------

PR Review: https://git.openjdk.org/leyden-docs/pull/1#pullrequestreview-2283154057
PR Comment: https://git.openjdk.org/leyden-docs/pull/1#issuecomment-2331756271

From heidinga at openjdk.org  Fri Sep  6 14:12:13 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 6 Sep 2024 14:12:13 GMT
Subject: Integrated: Update JVMLS talk links and add JVMLS 2024
In-Reply-To: <aWtByfTyI9W6ntUUFIxpco8LZz_ySxlzgZI2yizKGgs=.373798e4-61ba-4679-aa0f-b236a9fa8037@github.com>
References: <aWtByfTyI9W6ntUUFIxpco8LZz_ySxlzgZI2yizKGgs=.373798e4-61ba-4679-aa0f-b236a9fa8037@github.com>
Message-ID: <5Htus7ANcSKC8CF5HsjD9P5M7JmESyrEIAvDGgVajMM=.88b5cbcd-fca5-4a6f-9020-71cb59b6c86c@github.com>

On Wed, 4 Sep 2024 16:25:42 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

> Update links and add JVMLS 2024 talk

Thanks Mark.  I've updated the commit and the title

-------------

PR Comment: https://git.openjdk.org/leyden-docs/pull/1#issuecomment-2331782526

From heidinga at openjdk.org  Fri Sep  6 14:12:13 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 6 Sep 2024 14:12:13 GMT
Subject: Integrated: Update JVMLS talk links and add JVMLS 2024
In-Reply-To: <aWtByfTyI9W6ntUUFIxpco8LZz_ySxlzgZI2yizKGgs=.373798e4-61ba-4679-aa0f-b236a9fa8037@github.com>
References: <aWtByfTyI9W6ntUUFIxpco8LZz_ySxlzgZI2yizKGgs=.373798e4-61ba-4679-aa0f-b236a9fa8037@github.com>
Message-ID: <E49sCzaCmIs0EquXigLkmJtHKhb9NL7WdG6PGIXA9-I=.83fbf4b4-38c4-4965-b5e3-dcaaa0dc3b66@github.com>

On Wed, 4 Sep 2024 16:25:42 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

> Update links and add JVMLS 2024 talk

This pull request has now been integrated.

Changeset: f6e3a877
Author:    Dan Heidinga <heidinga at openjdk.org>
URL:       https://git.openjdk.org/leyden-docs/commit/f6e3a8773d80e17f09b81258ee34dcda6a6c7caf
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

Update JVMLS talk links and add JVMLS 2024

Reviewed-by: mr

-------------

PR: https://git.openjdk.org/leyden-docs/pull/1

From heidinga at openjdk.org  Fri Sep  6 14:49:38 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 6 Sep 2024 14:49:38 GMT
Subject: git: openjdk/leyden-docs: master: Publish: Thoughts on Training Runs
Message-ID: <0a5d3af9-2fde-4f9a-a59e-31f92a972b42@openjdk.org>

Changeset: 8a1dbb9e
Branch: master
Author:    Dan Heidinga <heidinga at openjdk.org>
Date:      2024-09-06 14:47:52 +0000
URL:       https://git.openjdk.org/leyden-docs/commit/8a1dbb9e09d952b777fa8351f0d263cad31125ae

Publish: Thoughts on Training Runs

Reviewed-by: mr

+ site/notes/05-training-runs.md


From heidinga at openjdk.org  Fri Sep  6 14:50:16 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 6 Sep 2024 14:50:16 GMT
Subject: Integrated: Publish: Thoughts on Training Runs
In-Reply-To: <SQm-Q9Wyohx-EP66GZ1olDfRE-wOY_qUTwm431D3qg8=.4360c8bb-7fa3-4fe4-8014-65090796a009@github.com>
References: <SQm-Q9Wyohx-EP66GZ1olDfRE-wOY_qUTwm431D3qg8=.4360c8bb-7fa3-4fe4-8014-65090796a009@github.com>
Message-ID: <HoctQoY1QF7Jolx-C70Jkhjh-x5XQMMk8tYGFOJqoiI=.25eeca26-213f-4f61-bbd0-a199d4efe69e@github.com>

On Wed, 4 Sep 2024 20:24:01 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

> Publish the writeup on training runs

This pull request has now been integrated.

Changeset: 8a1dbb9e
Author:    Dan Heidinga <heidinga at openjdk.org>
URL:       https://git.openjdk.org/leyden-docs/commit/8a1dbb9e09d952b777fa8351f0d263cad31125ae
Stats:     131 lines in 1 file changed: 131 ins; 0 del; 0 mod

Publish: Thoughts on Training Runs

Reviewed-by: mr

-------------

PR: https://git.openjdk.org/leyden-docs/pull/3

From kvn at openjdk.org  Fri Sep  6 16:06:30 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 6 Sep 2024 16:06:30 GMT
Subject: RFR: Workaround CacheDataStore use with source launcher [v2]
In-Reply-To: <WrCeEeFVm7bxm4NUhgdyT37ps3yEIqi81CM7UH86Ft4=.b0e35ac9-debe-4964-8ae0-c1b12cce5e34@github.com>
References: <YAyYOvD-NbB0hcUwUF9xCGmHkT0RDNLYXKdHSXRy0nY=.d338e229-985d-47ec-a6be-42ec8060d187@github.com>
 <WrCeEeFVm7bxm4NUhgdyT37ps3yEIqi81CM7UH86Ft4=.b0e35ac9-debe-4964-8ae0-c1b12cce5e34@github.com>
Message-ID: <P9O2ELDB8VEk66iDlhPNTEAEnx4DwReS5OGwrUSZsDY=.6722a91d-5d46-4978-a6dc-ed541a004f32@github.com>

On Fri, 6 Sep 2024 08:59:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I was trying to test the simplest workload that involves javac, and that is source launcher. When I attempt to use source launcher with `-XX:CacheDataStore`, it fails with:
>> 
>> 
>> $ rm -f app.cds*; build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC HelloStream.java
>> [0.001s][warning][cds] optimized module handling/full module graph: disabled due to incompatible property: jdk.module.addmods=ALL-DEFAULT
>> Error occurred during initialization of VM
>> CacheDataStore cannot be created because AOTClassLinking is enabled but full module graph is disabled
>> 
>> 
>> Source launcher adds `--add-modules=ALL-DEFAULT`:
>> 
>> 
>> $ man java
>> ...
>>        In source-file mode, execution proceeds as follows:
>> 
>> ...
>>        ? The compiled classes are executed in  the  context  of  an  unnamed  module,  as  though  --add-mod?
>>          ules=ALL-DEFAULT  is  in  effect.  This is in addition to any other --add-module options that may be
>>          have been specified on the command line.
>> 
>> 
>> I think we can work that around specifically for Leyden, and also leave a TODO breadcrumb in the code that we need to figure this out on CDS side. This PR does that workaround. With it, source launcher works with simple examples:
>> 
>> 
>> $ build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC  HelloStream.java
>> Warning: CacheDataStore cannot be used with default source launcher environment, disabling --add-modules=ALL-DEFAULT
>> hello, world
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Indenting

We are trying  to avoid change Java launcher to check Leyden flags (especially -XX:) if we can do changes in VM.
See discussion in PR: https://github.com/openjdk/jdk/pull/20516

-------------

PR Comment: https://git.openjdk.org/leyden/pull/15#issuecomment-2334375352

From shade at openjdk.org  Fri Sep  6 16:20:26 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 6 Sep 2024 16:20:26 GMT
Subject: RFR: Workaround CacheDataStore use with source launcher [v2]
In-Reply-To: <WrCeEeFVm7bxm4NUhgdyT37ps3yEIqi81CM7UH86Ft4=.b0e35ac9-debe-4964-8ae0-c1b12cce5e34@github.com>
References: <YAyYOvD-NbB0hcUwUF9xCGmHkT0RDNLYXKdHSXRy0nY=.d338e229-985d-47ec-a6be-42ec8060d187@github.com>
 <WrCeEeFVm7bxm4NUhgdyT37ps3yEIqi81CM7UH86Ft4=.b0e35ac9-debe-4964-8ae0-c1b12cce5e34@github.com>
Message-ID: <Ktik70L8Emsf7ZbluTcbM9ziE6Oj67GHHtr4wR-mzQQ=.45ab62d4-a7fe-46b4-b643-1c2eab9e7465@github.com>

On Fri, 6 Sep 2024 08:59:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I was trying to test the simplest workload that involves javac, and that is source launcher. When I attempt to use source launcher with `-XX:CacheDataStore`, it fails with:
>> 
>> 
>> $ rm -f app.cds*; build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC HelloStream.java
>> [0.001s][warning][cds] optimized module handling/full module graph: disabled due to incompatible property: jdk.module.addmods=ALL-DEFAULT
>> Error occurred during initialization of VM
>> CacheDataStore cannot be created because AOTClassLinking is enabled but full module graph is disabled
>> 
>> 
>> Source launcher adds `--add-modules=ALL-DEFAULT`:
>> 
>> 
>> $ man java
>> ...
>>        In source-file mode, execution proceeds as follows:
>> 
>> ...
>>        ? The compiled classes are executed in  the  context  of  an  unnamed  module,  as  though  --add-mod?
>>          ules=ALL-DEFAULT  is  in  effect.  This is in addition to any other --add-module options that may be
>>          have been specified on the command line.
>> 
>> 
>> I think we can work that around specifically for Leyden, and also leave a TODO breadcrumb in the code that we need to figure this out on CDS side. This PR does that workaround. With it, source launcher works with simple examples:
>> 
>> 
>> $ build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC  HelloStream.java
>> Warning: CacheDataStore cannot be used with default source launcher environment, disabling --add-modules=ALL-DEFAULT
>> hello, world
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Indenting

> We are trying to avoid change Java launcher to check Leyden flags (especially -XX:) if we can do changes in VM. See discussion in PR: [openjdk/jdk#20516](https://github.com/openjdk/jdk/pull/20516)

Yeah, I understand we don't want to change launcher if we can avoid it. The actual trouble is on CDS side and how `--add-modules=ALL-DEFAULT` disables `CacheDataStore`. Given that most (if not all?) source-launched examples I saw do not require modules enabled, this breakage is for naught. So _not_ doing `--add-modules` when CDS is enabled is a convenience for performance testing, plus a breadcrumb for future work.

This is similar in spirit to what we do for JVMCI modules:
https://github.com/openjdk/leyden/blob/cf036d707b1cecad037b5543a07649a55d59f0e2/src/hotspot/share/runtime/arguments.cpp#L1792-L1801

-------------

PR Comment: https://git.openjdk.org/leyden/pull/15#issuecomment-2334400021

From shade at openjdk.org  Fri Sep  6 16:27:40 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 6 Sep 2024 16:27:40 GMT
Subject: RFR: Workaround CacheDataStore use with source launcher [v2]
In-Reply-To: <Ktik70L8Emsf7ZbluTcbM9ziE6Oj67GHHtr4wR-mzQQ=.45ab62d4-a7fe-46b4-b643-1c2eab9e7465@github.com>
References: <YAyYOvD-NbB0hcUwUF9xCGmHkT0RDNLYXKdHSXRy0nY=.d338e229-985d-47ec-a6be-42ec8060d187@github.com>
 <WrCeEeFVm7bxm4NUhgdyT37ps3yEIqi81CM7UH86Ft4=.b0e35ac9-debe-4964-8ae0-c1b12cce5e34@github.com>
 <Ktik70L8Emsf7ZbluTcbM9ziE6Oj67GHHtr4wR-mzQQ=.45ab62d4-a7fe-46b4-b643-1c2eab9e7465@github.com>
Message-ID: <q2oC7U-so8p-C8MaQ2Xx6pR51d3nuXfmM36_7BtKssA=.2829e127-0ce6-40a7-9c62-b8787b3ee9ba@github.com>

On Fri, 6 Sep 2024 16:17:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> So _not_ doing `--add-modules` when CDS is enabled is a convenience for performance testing, plus a breadcrumb for future work.

We can move this check to VM, but it is not convenient to figure our if we are running in `LM_SOURCE` mode or not on the VM side.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/15#issuecomment-2334410780

From kvn at openjdk.org  Fri Sep  6 17:39:14 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 6 Sep 2024 17:39:14 GMT
Subject: RFR: Workaround CacheDataStore use with source launcher [v2]
In-Reply-To: <WrCeEeFVm7bxm4NUhgdyT37ps3yEIqi81CM7UH86Ft4=.b0e35ac9-debe-4964-8ae0-c1b12cce5e34@github.com>
References: <YAyYOvD-NbB0hcUwUF9xCGmHkT0RDNLYXKdHSXRy0nY=.d338e229-985d-47ec-a6be-42ec8060d187@github.com>
 <WrCeEeFVm7bxm4NUhgdyT37ps3yEIqi81CM7UH86Ft4=.b0e35ac9-debe-4964-8ae0-c1b12cce5e34@github.com>
Message-ID: <dmQq0OXJHBc4oZ5cITMIw3X0LzmIGzfOkLEVfLfMspk=.f9604e70-c9b7-4e3b-b362-8b04a4096c9c@github.com>

On Fri, 6 Sep 2024 08:59:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I was trying to test the simplest workload that involves javac, and that is source launcher. When I attempt to use source launcher with `-XX:CacheDataStore`, it fails with:
>> 
>> 
>> $ rm -f app.cds*; build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC HelloStream.java
>> [0.001s][warning][cds] optimized module handling/full module graph: disabled due to incompatible property: jdk.module.addmods=ALL-DEFAULT
>> Error occurred during initialization of VM
>> CacheDataStore cannot be created because AOTClassLinking is enabled but full module graph is disabled
>> 
>> 
>> Source launcher adds `--add-modules=ALL-DEFAULT`:
>> 
>> 
>> $ man java
>> ...
>>        In source-file mode, execution proceeds as follows:
>> 
>> ...
>>        ? The compiled classes are executed in  the  context  of  an  unnamed  module,  as  though  --add-mod?
>>          ules=ALL-DEFAULT  is  in  effect.  This is in addition to any other --add-module options that may be
>>          have been specified on the command line.
>> 
>> 
>> I think we can work that around specifically for Leyden, and also leave a TODO breadcrumb in the code that we need to figure this out on CDS side. This PR does that workaround. With it, source launcher works with simple examples:
>> 
>> 
>> $ build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC  HelloStream.java
>> Warning: CacheDataStore cannot be used with default source launcher environment, disabling --add-modules=ALL-DEFAULT
>> hello, world
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Indenting

Lets wait @iklam comment on this.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/15#issuecomment-2334525134

From iklam at openjdk.org  Fri Sep  6 18:09:56 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 6 Sep 2024 18:09:56 GMT
Subject: RFR: Workaround CacheDataStore use with source launcher [v2]
In-Reply-To: <WrCeEeFVm7bxm4NUhgdyT37ps3yEIqi81CM7UH86Ft4=.b0e35ac9-debe-4964-8ae0-c1b12cce5e34@github.com>
References: <YAyYOvD-NbB0hcUwUF9xCGmHkT0RDNLYXKdHSXRy0nY=.d338e229-985d-47ec-a6be-42ec8060d187@github.com>
 <WrCeEeFVm7bxm4NUhgdyT37ps3yEIqi81CM7UH86Ft4=.b0e35ac9-debe-4964-8ae0-c1b12cce5e34@github.com>
Message-ID: <plgDn6Gvu1m03PRVGHJlpg205DDwaOMAN0zAm4_fWCw=.20ebe166-6613-4bc9-8977-bab983cad1d6@github.com>

On Fri, 6 Sep 2024 08:59:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I was trying to test the simplest workload that involves javac, and that is source launcher. When I attempt to use source launcher with `-XX:CacheDataStore`, it fails with:
>> 
>> 
>> $ rm -f app.cds*; build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC HelloStream.java
>> [0.001s][warning][cds] optimized module handling/full module graph: disabled due to incompatible property: jdk.module.addmods=ALL-DEFAULT
>> Error occurred during initialization of VM
>> CacheDataStore cannot be created because AOTClassLinking is enabled but full module graph is disabled
>> 
>> 
>> Source launcher adds `--add-modules=ALL-DEFAULT`:
>> 
>> 
>> $ man java
>> ...
>>        In source-file mode, execution proceeds as follows:
>> 
>> ...
>>        ? The compiled classes are executed in  the  context  of  an  unnamed  module,  as  though  --add-mod?
>>          ules=ALL-DEFAULT  is  in  effect.  This is in addition to any other --add-module options that may be
>>          have been specified on the command line.
>> 
>> 
>> I think we can work that around specifically for Leyden, and also leave a TODO breadcrumb in the code that we need to figure this out on CDS side. This PR does that workaround. With it, source launcher works with simple examples:
>> 
>> 
>> $ build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC  HelloStream.java
>> Warning: CacheDataStore cannot be used with default source launcher environment, disabling --add-modules=ALL-DEFAULT
>> hello, world
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Indenting

I am not sure if Leyden should be targeting running the launcher with a Java source file. There are many things that we *could* do to make some things run a little faster, but I think we should resist the temptation in this case.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/15#issuecomment-2334575313

From shade at openjdk.org  Fri Sep  6 18:55:41 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 6 Sep 2024 18:55:41 GMT
Subject: RFR: Rework rich PrintCompilation logs
Message-ID: <zLhCmUJJNvTtr0OlHLVB-VhCd6PZJOrEk-Tj0BYnho0=.35fcaefe-4b14-492a-ab81-52dee3fef653@github.com>

I have been studying javac benchmark behavior, and current `PrintCompilation` logs are very useful to figure out how much time is spent in creation, queueing, work time for each task. Current logs are quite a bit confusing, though:
 - The columns are misindented
 - The precision is too low to capture short events: most of the times are zero
 - Output seems to rely on "now" timestamp, which depends on _when_ we print
 
This PR reworks the logs to be more straightforward.

Example before:


   S296 C0 Q229 3531      A  2       com.sun.tools.javac.parser.JavacParser::typeName (37 bytes)
   S296 C0 Q245 2030      A  2       com.sun.tools.javac.tree.TreeInfo::innermostType (102 bytes)
   S296 C0 Q0 4169         3       com.sun.tools.javac.comp.Flow$AliveAnalyzer$$Lambda/0x800000105::accept (12 bytes)
   S296 C0 Q245 2042      A  2       com.sun.tools.javac.tree.JCTree$JCPrimitiveTypeTree::accept (9 bytes)
   S296 C0 Q0 4170         3       com.sun.tools.javac.comp.Flow$AssignAnalyzer$$Lambda/0x800000108::accept (12 bytes)
   S296 C0 Q0 4171         3       com.sun.tools.javac.comp.Flow$FlowAnalyzer$$Lambda/0x80000010a::accept (12 bytes)
   S296 C0 Q245 2098      A  2       com.sun.tools.javac.code.Symbol$RecordComponent::getOriginalAnnos (24 bytes)
   S296 C0 Q244 2348      A  2       com.sun.tools.javac.tree.TreeCopier::visitPrimitiveType (24 bytes)
   S296 C0 Q244 2349      A  2       com.sun.tools.javac.tree.TreeCopier::visitPrimitiveType (7 bytes)


Example after:


    346    C0.0                   4146         3       com.sun.tools.javac.comp.Check::checkAllDefined (66 bytes)
    346    C0.0    Q0.0    W0.1   4144         3       com.sun.tools.javac.comp.Attr$$Lambda/0x80000004f::<init> (10 bytes)
    346    C0.6  Q281.9    W0.1   3535      A  2       com.sun.tools.javac.parser.JavacParser::variableDeclaratorId (529 bytes)
    346    C0.0                   4148         3       com.sun.tools.javac.comp.Check::checkDefaultMethodClashes (383 bytes)
    346    C0.0    Q0.0    W0.1   4145         3       com.sun.tools.javac.comp.Attr$$Lambda/0x800000052::test (8 bytes)
    346    C0.4                   2631      A  2       com.sun.tools.javac.jvm.Items$ImmediateItem::numericValue (14 bytes)
    346    C0.0                   4149         3       com.sun.tools.javac.comp.Check::checkPotentiallyAmbiguousOverloads (79 bytes)
    346    C0.4  Q295.2    W0.0   2631      A  2       com.sun.tools.javac.jvm.Items$ImmediateItem::numericValue (14 bytes)
    346    C0.1                   2790      A  2       java.lang.invoke.InnerClassLambdaMetafactory::methodDesc (45 bytes)
    346    C0.1  Q294.5    W0.0   2790      A  2       java.lang.invoke.InnerClassLambdaMetafactory::methodDesc (45 bytes)


Note this effectively prints the task twice: one in the "usual" place we do it (near task creation), and one at the end, when we know all counters are populated and trustworthy.

-------------

Commit messages:
 - Work

Changes: https://git.openjdk.org/leyden/pull/16/files
  Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=16&range=00
  Stats: 40 lines in 3 files changed: 23 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/leyden/pull/16.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/16/head:pull/16

PR: https://git.openjdk.org/leyden/pull/16

From shade at openjdk.org  Fri Sep  6 18:56:44 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 6 Sep 2024 18:56:44 GMT
Subject: RFR: Workaround CacheDataStore use with source launcher [v2]
In-Reply-To: <WrCeEeFVm7bxm4NUhgdyT37ps3yEIqi81CM7UH86Ft4=.b0e35ac9-debe-4964-8ae0-c1b12cce5e34@github.com>
References: <YAyYOvD-NbB0hcUwUF9xCGmHkT0RDNLYXKdHSXRy0nY=.d338e229-985d-47ec-a6be-42ec8060d187@github.com>
 <WrCeEeFVm7bxm4NUhgdyT37ps3yEIqi81CM7UH86Ft4=.b0e35ac9-debe-4964-8ae0-c1b12cce5e34@github.com>
Message-ID: <jgO-dsvokYB9OiAKSGGiiqPqOcScjBGusY0_LemnEA0=.4fe93e3b-58f9-4048-bb58-f864646376ff@github.com>

On Fri, 6 Sep 2024 08:59:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I was trying to test the simplest workload that involves javac, and that is source launcher. When I attempt to use source launcher with `-XX:CacheDataStore`, it fails with:
>> 
>> 
>> $ rm -f app.cds*; build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC HelloStream.java
>> [0.001s][warning][cds] optimized module handling/full module graph: disabled due to incompatible property: jdk.module.addmods=ALL-DEFAULT
>> Error occurred during initialization of VM
>> CacheDataStore cannot be created because AOTClassLinking is enabled but full module graph is disabled
>> 
>> 
>> Source launcher adds `--add-modules=ALL-DEFAULT`:
>> 
>> 
>> $ man java
>> ...
>>        In source-file mode, execution proceeds as follows:
>> 
>> ...
>>        ? The compiled classes are executed in  the  context  of  an  unnamed  module,  as  though  --add-mod?
>>          ules=ALL-DEFAULT  is  in  effect.  This is in addition to any other --add-module options that may be
>>          have been specified on the command line.
>> 
>> 
>> I think we can work that around specifically for Leyden, and also leave a TODO breadcrumb in the code that we need to figure this out on CDS side. This PR does that workaround. With it, source launcher works with simple examples:
>> 
>> 
>> $ build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC  HelloStream.java
>> Warning: CacheDataStore cannot be used with default source launcher environment, disabling --add-modules=ALL-DEFAULT
>> hello, world
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Indenting

I think what Leyden _targets_ is a different question.

After a day of playing with this, I think enabling source launcher does look very convenient for current performance testing, as it includes javac automatically, without any additional setup. I am not insisting on doing this workaround, it is just a handy development aid. If you all feel strongly against it, I can go the longer and less convenient route to measure CDS perf.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/15#issuecomment-2334640218

From kvn at openjdk.org  Fri Sep  6 19:09:19 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 6 Sep 2024 19:09:19 GMT
Subject: RFR: Rework rich PrintCompilation logs
In-Reply-To: <zLhCmUJJNvTtr0OlHLVB-VhCd6PZJOrEk-Tj0BYnho0=.35fcaefe-4b14-492a-ab81-52dee3fef653@github.com>
References: <zLhCmUJJNvTtr0OlHLVB-VhCd6PZJOrEk-Tj0BYnho0=.35fcaefe-4b14-492a-ab81-52dee3fef653@github.com>
Message-ID: <TyPA7haX-cxEaj0XKpvntxz6VmdQxBVxbM6Rjx8_E1U=.a2e6b24d-e30b-41e2-8dd9-42f00c44c713@github.com>

On Fri, 6 Sep 2024 18:49:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have been studying javac benchmark behavior, and current `PrintCompilation` logs are very useful to figure out how much time is spent in creation, queueing, work time for each task. Current logs are quite a bit confusing, though:
>  - The columns are misindented
>  - The precision is too low to capture short events: most of the times are zero
>  - Output seems to rely on "now" timestamp, which depends on _when_ we print
>  
> This PR reworks the logs to be more straightforward.
> 
> Example before:
> 
> 
>    S296 C0 Q229 3531      A  2       com.sun.tools.javac.parser.JavacParser::typeName (37 bytes)
>    S296 C0 Q245 2030      A  2       com.sun.tools.javac.tree.TreeInfo::innermostType (102 bytes)
>    S296 C0 Q0 4169         3       com.sun.tools.javac.comp.Flow$AliveAnalyzer$$Lambda/0x800000105::accept (12 bytes)
>    S296 C0 Q245 2042      A  2       com.sun.tools.javac.tree.JCTree$JCPrimitiveTypeTree::accept (9 bytes)
>    S296 C0 Q0 4170         3       com.sun.tools.javac.comp.Flow$AssignAnalyzer$$Lambda/0x800000108::accept (12 bytes)
>    S296 C0 Q0 4171         3       com.sun.tools.javac.comp.Flow$FlowAnalyzer$$Lambda/0x80000010a::accept (12 bytes)
>    S296 C0 Q245 2098      A  2       com.sun.tools.javac.code.Symbol$RecordComponent::getOriginalAnnos (24 bytes)
>    S296 C0 Q244 2348      A  2       com.sun.tools.javac.tree.TreeCopier::visitPrimitiveType (24 bytes)
>    S296 C0 Q244 2349      A  2       com.sun.tools.javac.tree.TreeCopier::visitPrimitiveType (7 bytes)
> 
> 
> Example after:
> 
> 
>     346    C0.0                   4146         3       com.sun.tools.javac.comp.Check::checkAllDefined (66 bytes)
>     346    C0.0    Q0.0    W0.1   4144         3       com.sun.tools.javac.comp.Attr$$Lambda/0x80000004f::<init> (10 bytes)
>     346    C0.6  Q281.9    W0.1   3535      A  2       com.sun.tools.javac.parser.JavacParser::variableDeclaratorId (529 bytes)
>     346    C0.0                   4148         3       com.sun.tools.javac.comp.Check::checkDefaultMethodClashes (383 bytes)
>     346    C0.0    Q0.0    W0.1   4145         3       com.sun.tools.javac.comp.Attr$$Lambda/0x800000052::test (8 bytes)
>     346    C0.4                   2631      A  2       com.sun.tools.javac.jvm.Items$ImmediateItem::numericValue (14 bytes)
>     346    C0.0                   4149         3       com.sun.tools.javac.comp.Check::checkPotentiallyAmbiguousOverloads (79 bytes)
>     346    C0.4  Q295.2    W0.0   2631      A  2       com.sun.tools.javac.jvm.Items$ImmediateItem::numericValue (14 bytes)
>     346    C0.1  ...

I would swap `C` <-> `W`. `C` - compilation time. `W` - wait until put on queue.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/16#issuecomment-2334658894

From iklam at openjdk.org  Fri Sep  6 19:11:14 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 6 Sep 2024 19:11:14 GMT
Subject: RFR: Workaround CacheDataStore use with source launcher [v2]
In-Reply-To: <WrCeEeFVm7bxm4NUhgdyT37ps3yEIqi81CM7UH86Ft4=.b0e35ac9-debe-4964-8ae0-c1b12cce5e34@github.com>
References: <YAyYOvD-NbB0hcUwUF9xCGmHkT0RDNLYXKdHSXRy0nY=.d338e229-985d-47ec-a6be-42ec8060d187@github.com>
 <WrCeEeFVm7bxm4NUhgdyT37ps3yEIqi81CM7UH86Ft4=.b0e35ac9-debe-4964-8ae0-c1b12cce5e34@github.com>
Message-ID: <J1ocWmtNMNwaXFwihEwn9T5cOFEScvugXfsG2Sz8q-0=.21c254be-5eec-4c21-83b6-ba7d9162ec41@github.com>

On Fri, 6 Sep 2024 08:59:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I was trying to test the simplest workload that involves javac, and that is source launcher. When I attempt to use source launcher with `-XX:CacheDataStore`, it fails with:
>> 
>> 
>> $ rm -f app.cds*; build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC HelloStream.java
>> [0.001s][warning][cds] optimized module handling/full module graph: disabled due to incompatible property: jdk.module.addmods=ALL-DEFAULT
>> Error occurred during initialization of VM
>> CacheDataStore cannot be created because AOTClassLinking is enabled but full module graph is disabled
>> 
>> 
>> Source launcher adds `--add-modules=ALL-DEFAULT`:
>> 
>> 
>> $ man java
>> ...
>>        In source-file mode, execution proceeds as follows:
>> 
>> ...
>>        ? The compiled classes are executed in  the  context  of  an  unnamed  module,  as  though  --add-mod?
>>          ules=ALL-DEFAULT  is  in  effect.  This is in addition to any other --add-module options that may be
>>          have been specified on the command line.
>> 
>> 
>> I think we can work that around specifically for Leyden, and also leave a TODO breadcrumb in the code that we need to figure this out on CDS side. This PR does that workaround. With it, source launcher works with simple examples:
>> 
>> 
>> $ build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC  HelloStream.java
>> Warning: CacheDataStore cannot be used with default source launcher environment, disabling --add-modules=ALL-DEFAULT
>> hello, world
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Indenting

But you will be adding javac timing to every one of your benchmarks. Is this really what you want?

If you want convenience, I think it's better to write a simple/generic script that compiles the Java source into a JAR file and then do it the usual way.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/15#issuecomment-2334660516

From shade at openjdk.org  Fri Sep  6 19:15:16 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 6 Sep 2024 19:15:16 GMT
Subject: RFR: Workaround CacheDataStore use with source launcher [v2]
In-Reply-To: <J1ocWmtNMNwaXFwihEwn9T5cOFEScvugXfsG2Sz8q-0=.21c254be-5eec-4c21-83b6-ba7d9162ec41@github.com>
References: <YAyYOvD-NbB0hcUwUF9xCGmHkT0RDNLYXKdHSXRy0nY=.d338e229-985d-47ec-a6be-42ec8060d187@github.com>
 <WrCeEeFVm7bxm4NUhgdyT37ps3yEIqi81CM7UH86Ft4=.b0e35ac9-debe-4964-8ae0-c1b12cce5e34@github.com>
 <J1ocWmtNMNwaXFwihEwn9T5cOFEScvugXfsG2Sz8q-0=.21c254be-5eec-4c21-83b6-ba7d9162ec41@github.com>
Message-ID: <dDj5U5pvvrrQzseK3lWS6jrpxqrAvv_4lvS8DXSRo7o=.69ff110b-18c3-4be0-aa10-9eecf6be4e61@github.com>

On Fri, 6 Sep 2024 19:08:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> But you will be adding javac timing to every one of your benchmarks. Is this really what you want?

Yes, it is exactly that: the easiest way for me to target both javac and the app is to add `.java` to my command line :)

-------------

PR Comment: https://git.openjdk.org/leyden/pull/15#issuecomment-2334665969

From shade at openjdk.org  Fri Sep  6 19:53:45 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 6 Sep 2024 19:53:45 GMT
Subject: RFR: Prefer to take AOT method from the SC queue faster
Message-ID: <UI6YxQPC4UNRak-EY7H1jrBRdaBpFKm1V7H05VMRbLI=.9e6a634b-b1f1-4136-80f6-dd1b9f47007b@github.com>

Probably WIP. Humor me for a second: why could not / should not we take the AOT task for "compilation" (installation, really) right away like this? I suspect when SC queues are overwhelmed with N elements, we keep walking the entire SC queue for no particular reason?

This improves javac benchmark considerably (look at both wall time and user time):


# BEFORE
Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp JavacBenchApp.jar JavacBenchApp 50
  Time (mean ? ?):     348.3 ms ?   2.8 ms    [User: 949.0 ms, System: 101.4 ms]
  Range (min ? max):   344.0 ms ? 355.3 ms    100 runs

# AFTER
Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp JavacBenchApp.jar JavacBenchApp 50
  Time (mean ? ?):     312.2 ms ?   2.6 ms    [User: 577.8 ms, System: 95.4 ms]
  Range (min ? max):   307.1 ms ? 318.5 ms    100 runs

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/leyden/pull/17/files
  Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=17&range=00
  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/leyden/pull/17.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/17/head:pull/17

PR: https://git.openjdk.org/leyden/pull/17

From shade at openjdk.org  Fri Sep  6 19:54:30 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 6 Sep 2024 19:54:30 GMT
Subject: RFR: Rework rich PrintCompilation logs [v2]
In-Reply-To: <zLhCmUJJNvTtr0OlHLVB-VhCd6PZJOrEk-Tj0BYnho0=.35fcaefe-4b14-492a-ab81-52dee3fef653@github.com>
References: <zLhCmUJJNvTtr0OlHLVB-VhCd6PZJOrEk-Tj0BYnho0=.35fcaefe-4b14-492a-ab81-52dee3fef653@github.com>
Message-ID: <nCKp32Rc6Ci2_9c9_YxEEqKsXQDeAUz9niNTP5CqpZA=.8c4c360b-85b1-4b0d-b22a-7d787e893ae3@github.com>

> I have been studying javac benchmark behavior, and current `PrintCompilation` logs are very useful to figure out how much time is spent in creation, queueing, work time for each task. Current logs are quite a bit confusing, though:
>  - The columns are misindented
>  - The precision is too low to capture short events: most of the times are zero
>  - Output seems to rely on "now" timestamp, which depends on _when_ we print
>  
> This PR reworks the logs to be more straightforward.
> 
> Example before:
> 
> 
>    S296 C0 Q229 3531      A  2       com.sun.tools.javac.parser.JavacParser::typeName (37 bytes)
>    S296 C0 Q245 2030      A  2       com.sun.tools.javac.tree.TreeInfo::innermostType (102 bytes)
>    S296 C0 Q0 4169         3       com.sun.tools.javac.comp.Flow$AliveAnalyzer$$Lambda/0x800000105::accept (12 bytes)
>    S296 C0 Q245 2042      A  2       com.sun.tools.javac.tree.JCTree$JCPrimitiveTypeTree::accept (9 bytes)
>    S296 C0 Q0 4170         3       com.sun.tools.javac.comp.Flow$AssignAnalyzer$$Lambda/0x800000108::accept (12 bytes)
>    S296 C0 Q0 4171         3       com.sun.tools.javac.comp.Flow$FlowAnalyzer$$Lambda/0x80000010a::accept (12 bytes)
>    S296 C0 Q245 2098      A  2       com.sun.tools.javac.code.Symbol$RecordComponent::getOriginalAnnos (24 bytes)
>    S296 C0 Q244 2348      A  2       com.sun.tools.javac.tree.TreeCopier::visitPrimitiveType (24 bytes)
>    S296 C0 Q244 2349      A  2       com.sun.tools.javac.tree.TreeCopier::visitPrimitiveType (7 bytes)
> 
> 
> Example after:
> 
> 
>     386    W0.0  Q313.7    C0.2   3524   !  A  2       com.sun.tools.javac.parser.JavacParser::literal (655 bytes)
>     386                           3858         3       java.util.stream.MatchOps$$Lambda/0x800000030::<init> (15 bytes)   made not entrant
>     386    W0.1                   2416      A  1       com.sun.tools.javac.comp.Infer$CheckInst::boundsToCheck (5 bytes)
>     386    W0.0    Q0.1    C0.2   4155         4       java.util.stream.MatchOps$$Lambda/0x800000030::<init> (15 bytes)
>     386    W0.1  Q332.7    C0.0   2416      A  1       com.sun.tools.javac.comp.Infer$CheckInst::boundsToCheck (5 bytes)
>     386    W0.2                   2902      A  2       com.sun.tools.javac.code.ClassFinder::classFileNotFound (13 bytes)
>     386    W0.2  Q327.9    C0.0   2902      A  2       com.sun.tools.javac.code.ClassFinder::classFileNotFound (13 bytes)
>     386    W0.0                   3527      A  2       com.sun.tools.javac.parser.JavacParser::parseExpression (6 bytes)
>     386    W0.0  Q314.2    C0...

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Swap W<->C

-------------

Changes:
  - all: https://git.openjdk.org/leyden/pull/16/files
  - new: https://git.openjdk.org/leyden/pull/16/files/f07c3d87..ae2db2cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=leyden&pr=16&range=01
 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=16&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/leyden/pull/16.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/16/head:pull/16

PR: https://git.openjdk.org/leyden/pull/16

From shade at openjdk.org  Fri Sep  6 19:54:31 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 6 Sep 2024 19:54:31 GMT
Subject: RFR: Rework rich PrintCompilation logs
In-Reply-To: <TyPA7haX-cxEaj0XKpvntxz6VmdQxBVxbM6Rjx8_E1U=.a2e6b24d-e30b-41e2-8dd9-42f00c44c713@github.com>
References: <zLhCmUJJNvTtr0OlHLVB-VhCd6PZJOrEk-Tj0BYnho0=.35fcaefe-4b14-492a-ab81-52dee3fef653@github.com>
 <TyPA7haX-cxEaj0XKpvntxz6VmdQxBVxbM6Rjx8_E1U=.a2e6b24d-e30b-41e2-8dd9-42f00c44c713@github.com>
Message-ID: <rsT7U63gcNM4i6ErbqOAbCPIrVZGVLWmNkhZ8aUlQ9A=.3c2dc78b-e097-4d84-bedb-5db53b3a5d79@github.com>

On Fri, 6 Sep 2024 19:07:00 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I would swap `C` <-> `W`. `C` - compilation time. `W` - wait until put on queue.

Yeah, that works even better, done in new commit. Updated PR body with a sample.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/16#issuecomment-2334715346

From kvn at openjdk.org  Fri Sep  6 20:29:17 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 6 Sep 2024 20:29:17 GMT
Subject: RFR: Rework rich PrintCompilation logs [v2]
In-Reply-To: <nCKp32Rc6Ci2_9c9_YxEEqKsXQDeAUz9niNTP5CqpZA=.8c4c360b-85b1-4b0d-b22a-7d787e893ae3@github.com>
References: <zLhCmUJJNvTtr0OlHLVB-VhCd6PZJOrEk-Tj0BYnho0=.35fcaefe-4b14-492a-ab81-52dee3fef653@github.com>
 <nCKp32Rc6Ci2_9c9_YxEEqKsXQDeAUz9niNTP5CqpZA=.8c4c360b-85b1-4b0d-b22a-7d787e893ae3@github.com>
Message-ID: <6_uricGxQBHSu1pwSHJGUKnFbTDx7qasCRfi200tvC0=.07ac99f8-8e10-4b47-b889-6df550cc8e2a@github.com>

On Fri, 6 Sep 2024 19:54:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have been studying javac benchmark behavior, and current `PrintCompilation` logs are very useful to figure out how much time is spent in creation, queueing, work time for each task. Current logs are quite a bit confusing, though:
>>  - The columns are misindented
>>  - The precision is too low to capture short events: most of the times are zero
>>  - Output seems to rely on "now" timestamp, which depends on _when_ we print
>>  
>> This PR reworks the logs to be more straightforward.
>> 
>> Example before:
>> 
>> 
>>    S296 C0 Q229 3531      A  2       com.sun.tools.javac.parser.JavacParser::typeName (37 bytes)
>>    S296 C0 Q245 2030      A  2       com.sun.tools.javac.tree.TreeInfo::innermostType (102 bytes)
>>    S296 C0 Q0 4169         3       com.sun.tools.javac.comp.Flow$AliveAnalyzer$$Lambda/0x800000105::accept (12 bytes)
>>    S296 C0 Q245 2042      A  2       com.sun.tools.javac.tree.JCTree$JCPrimitiveTypeTree::accept (9 bytes)
>>    S296 C0 Q0 4170         3       com.sun.tools.javac.comp.Flow$AssignAnalyzer$$Lambda/0x800000108::accept (12 bytes)
>>    S296 C0 Q0 4171         3       com.sun.tools.javac.comp.Flow$FlowAnalyzer$$Lambda/0x80000010a::accept (12 bytes)
>>    S296 C0 Q245 2098      A  2       com.sun.tools.javac.code.Symbol$RecordComponent::getOriginalAnnos (24 bytes)
>>    S296 C0 Q244 2348      A  2       com.sun.tools.javac.tree.TreeCopier::visitPrimitiveType (24 bytes)
>>    S296 C0 Q244 2349      A  2       com.sun.tools.javac.tree.TreeCopier::visitPrimitiveType (7 bytes)
>> 
>> 
>> Example after:
>> 
>> 
>>     386    W0.0  Q313.7    C0.2   3524   !  A  2       com.sun.tools.javac.parser.JavacParser::literal (655 bytes)
>>     386                           3858         3       java.util.stream.MatchOps$$Lambda/0x800000030::<init> (15 bytes)   made not entrant
>>     386    W0.1                   2416      A  1       com.sun.tools.javac.comp.Infer$CheckInst::boundsToCheck (5 bytes)
>>     386    W0.0    Q0.1    C0.2   4155         4       java.util.stream.MatchOps$$Lambda/0x800000030::<init> (15 bytes)
>>     386    W0.1  Q332.7    C0.0   2416      A  1       com.sun.tools.javac.comp.Infer$CheckInst::boundsToCheck (5 bytes)
>>     386    W0.2                   2902      A  2       com.sun.tools.javac.code.ClassFinder::classFileNotFound (13 bytes)
>>     386    W0.2  Q327.9    C0.0   2902      A  2       com.sun.tools.javac.code.ClassFinder::classFileNotFound (13 bytes)
>>     386    W0.0                   3527      A  2       com.sun.tools.javac.parser.Java...
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Swap W<->C

Good.

-------------

Marked as reviewed by kvn (Committer).

PR Review: https://git.openjdk.org/leyden/pull/16#pullrequestreview-2287108897

From shade at openjdk.org  Fri Sep  6 21:14:37 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 6 Sep 2024 21:14:37 GMT
Subject: RFR: Rework rich PrintCompilation logs [v2]
In-Reply-To: <nCKp32Rc6Ci2_9c9_YxEEqKsXQDeAUz9niNTP5CqpZA=.8c4c360b-85b1-4b0d-b22a-7d787e893ae3@github.com>
References: <zLhCmUJJNvTtr0OlHLVB-VhCd6PZJOrEk-Tj0BYnho0=.35fcaefe-4b14-492a-ab81-52dee3fef653@github.com>
 <nCKp32Rc6Ci2_9c9_YxEEqKsXQDeAUz9niNTP5CqpZA=.8c4c360b-85b1-4b0d-b22a-7d787e893ae3@github.com>
Message-ID: <FHxPx8iVU7jBVIGznJ7zovGUMd3pFq-Gn0lA0fpie_c=.562b667a-df34-4d3c-97cd-09a68b9e0e65@github.com>

On Fri, 6 Sep 2024 19:54:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have been studying javac benchmark behavior, and current `PrintCompilation` logs are very useful to figure out how much time is spent in creation, queueing, work time for each task. Current logs are quite a bit confusing, though:
>>  - The columns are misindented
>>  - The precision is too low to capture short events: most of the times are zero
>>  - Output seems to rely on "now" timestamp, which depends on _when_ we print
>>  
>> This PR reworks the logs to be more straightforward.
>> 
>> Example before:
>> 
>> 
>>    S296 C0 Q229 3531      A  2       com.sun.tools.javac.parser.JavacParser::typeName (37 bytes)
>>    S296 C0 Q245 2030      A  2       com.sun.tools.javac.tree.TreeInfo::innermostType (102 bytes)
>>    S296 C0 Q0 4169         3       com.sun.tools.javac.comp.Flow$AliveAnalyzer$$Lambda/0x800000105::accept (12 bytes)
>>    S296 C0 Q245 2042      A  2       com.sun.tools.javac.tree.JCTree$JCPrimitiveTypeTree::accept (9 bytes)
>>    S296 C0 Q0 4170         3       com.sun.tools.javac.comp.Flow$AssignAnalyzer$$Lambda/0x800000108::accept (12 bytes)
>>    S296 C0 Q0 4171         3       com.sun.tools.javac.comp.Flow$FlowAnalyzer$$Lambda/0x80000010a::accept (12 bytes)
>>    S296 C0 Q245 2098      A  2       com.sun.tools.javac.code.Symbol$RecordComponent::getOriginalAnnos (24 bytes)
>>    S296 C0 Q244 2348      A  2       com.sun.tools.javac.tree.TreeCopier::visitPrimitiveType (24 bytes)
>>    S296 C0 Q244 2349      A  2       com.sun.tools.javac.tree.TreeCopier::visitPrimitiveType (7 bytes)
>> 
>> 
>> Example after:
>> 
>> 
>>     386    W0.0  Q313.7    C0.2   3524   !  A  2       com.sun.tools.javac.parser.JavacParser::literal (655 bytes)
>>     386                           3858         3       java.util.stream.MatchOps$$Lambda/0x800000030::<init> (15 bytes)   made not entrant
>>     386    W0.1                   2416      A  1       com.sun.tools.javac.comp.Infer$CheckInst::boundsToCheck (5 bytes)
>>     386    W0.0    Q0.1    C0.2   4155         4       java.util.stream.MatchOps$$Lambda/0x800000030::<init> (15 bytes)
>>     386    W0.1  Q332.7    C0.0   2416      A  1       com.sun.tools.javac.comp.Infer$CheckInst::boundsToCheck (5 bytes)
>>     386    W0.2                   2902      A  2       com.sun.tools.javac.code.ClassFinder::classFileNotFound (13 bytes)
>>     386    W0.2  Q327.9    C0.0   2902      A  2       com.sun.tools.javac.code.ClassFinder::classFileNotFound (13 bytes)
>>     386    W0.0                   3527      A  2       com.sun.tools.javac.parser.Java...
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Swap W<->C

All platform builds complete, most platforms tests complete. This should be good enough.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/16#issuecomment-2334816248

From duke at openjdk.org  Fri Sep  6 21:14:37 2024
From: duke at openjdk.org (duke)
Date: Fri, 6 Sep 2024 21:14:37 GMT
Subject: RFR: Rework rich PrintCompilation logs [v2]
In-Reply-To: <nCKp32Rc6Ci2_9c9_YxEEqKsXQDeAUz9niNTP5CqpZA=.8c4c360b-85b1-4b0d-b22a-7d787e893ae3@github.com>
References: <zLhCmUJJNvTtr0OlHLVB-VhCd6PZJOrEk-Tj0BYnho0=.35fcaefe-4b14-492a-ab81-52dee3fef653@github.com>
 <nCKp32Rc6Ci2_9c9_YxEEqKsXQDeAUz9niNTP5CqpZA=.8c4c360b-85b1-4b0d-b22a-7d787e893ae3@github.com>
Message-ID: <HHP9CSWaO6NFOl2RiKhjHaRSasvpjylE03MQdeR_1gY=.7f0f8cc0-00e1-4b99-bc0e-9abc56ef89ad@github.com>

On Fri, 6 Sep 2024 19:54:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have been studying javac benchmark behavior, and current `PrintCompilation` logs are very useful to figure out how much time is spent in creation, queueing, work time for each task. Current logs are quite a bit confusing, though:
>>  - The columns are misindented
>>  - The precision is too low to capture short events: most of the times are zero
>>  - Output seems to rely on "now" timestamp, which depends on _when_ we print
>>  
>> This PR reworks the logs to be more straightforward.
>> 
>> Example before:
>> 
>> 
>>    S296 C0 Q229 3531      A  2       com.sun.tools.javac.parser.JavacParser::typeName (37 bytes)
>>    S296 C0 Q245 2030      A  2       com.sun.tools.javac.tree.TreeInfo::innermostType (102 bytes)
>>    S296 C0 Q0 4169         3       com.sun.tools.javac.comp.Flow$AliveAnalyzer$$Lambda/0x800000105::accept (12 bytes)
>>    S296 C0 Q245 2042      A  2       com.sun.tools.javac.tree.JCTree$JCPrimitiveTypeTree::accept (9 bytes)
>>    S296 C0 Q0 4170         3       com.sun.tools.javac.comp.Flow$AssignAnalyzer$$Lambda/0x800000108::accept (12 bytes)
>>    S296 C0 Q0 4171         3       com.sun.tools.javac.comp.Flow$FlowAnalyzer$$Lambda/0x80000010a::accept (12 bytes)
>>    S296 C0 Q245 2098      A  2       com.sun.tools.javac.code.Symbol$RecordComponent::getOriginalAnnos (24 bytes)
>>    S296 C0 Q244 2348      A  2       com.sun.tools.javac.tree.TreeCopier::visitPrimitiveType (24 bytes)
>>    S296 C0 Q244 2349      A  2       com.sun.tools.javac.tree.TreeCopier::visitPrimitiveType (7 bytes)
>> 
>> 
>> Example after:
>> 
>> 
>>     386    W0.0  Q313.7    C0.2   3524   !  A  2       com.sun.tools.javac.parser.JavacParser::literal (655 bytes)
>>     386                           3858         3       java.util.stream.MatchOps$$Lambda/0x800000030::<init> (15 bytes)   made not entrant
>>     386    W0.1                   2416      A  1       com.sun.tools.javac.comp.Infer$CheckInst::boundsToCheck (5 bytes)
>>     386    W0.0    Q0.1    C0.2   4155         4       java.util.stream.MatchOps$$Lambda/0x800000030::<init> (15 bytes)
>>     386    W0.1  Q332.7    C0.0   2416      A  1       com.sun.tools.javac.comp.Infer$CheckInst::boundsToCheck (5 bytes)
>>     386    W0.2                   2902      A  2       com.sun.tools.javac.code.ClassFinder::classFileNotFound (13 bytes)
>>     386    W0.2  Q327.9    C0.0   2902      A  2       com.sun.tools.javac.code.ClassFinder::classFileNotFound (13 bytes)
>>     386    W0.0                   3527      A  2       com.sun.tools.javac.parser.Java...
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Swap W<->C

@shipilev 
Your change (at version ae2db2cd57018a6d4f160d247282fe0dc77a1c06) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/16#issuecomment-2334816656

From kvn at openjdk.org  Fri Sep  6 22:14:30 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 6 Sep 2024 22:14:30 GMT
Subject: RFR: Prefer to take AOT method from the SC queue faster
In-Reply-To: <UI6YxQPC4UNRak-EY7H1jrBRdaBpFKm1V7H05VMRbLI=.9e6a634b-b1f1-4136-80f6-dd1b9f47007b@github.com>
References: <UI6YxQPC4UNRak-EY7H1jrBRdaBpFKm1V7H05VMRbLI=.9e6a634b-b1f1-4136-80f6-dd1b9f47007b@github.com>
Message-ID: <pQ4cnV9YC-_ZRBmxaAmwuSN1JMRTa2Rw2zFmNvsS3p4=.146fe2df-5ddc-4d1e-a112-2831df4a5902@github.com>

On Fri, 6 Sep 2024 19:41:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Probably WIP. Humor me for a second: why could not / should not we take the AOT task for "compilation" (installation, really) right away like this? I suspect when SC queues are overwhelmed with N elements, we keep walking the entire SC queue for no particular reason?
> 
> This improves javac benchmark considerably (look at both wall time and user time):
> 
> 
> # BEFORE
> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp JavacBenchApp.jar JavacBenchApp 50
>   Time (mean ? ?):     348.3 ms ?   2.8 ms    [User: 949.0 ms, System: 101.4 ms]
>   Range (min ? max):   344.0 ms ? 355.3 ms    100 runs
> 
> # AFTER
> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp JavacBenchApp.jar JavacBenchApp 50
>   Time (mean ? ?):     312.2 ms ?   2.6 ms    [User: 577.8 ms, System: 95.4 ms]
>   Range (min ? max):   307.1 ms ? 318.5 ms    100 runs

Currently we do that in `compare_task`:
https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/compiler/compilationPolicy.cpp#L1185

I was very conservative to immediately selecting SCC task because we put these task on normal compilation queues:
https://github.com/veresov/jdk/commit/76157f6e77346ef0b2c47497231210f1fd84b446

Now we have separate queues for these tasks. I thought I changed code how task is selected for these queues (using FIFO).

-------------

PR Comment: https://git.openjdk.org/leyden/pull/17#issuecomment-2334875489

From kvn at openjdk.org  Fri Sep  6 22:26:19 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 6 Sep 2024 22:26:19 GMT
Subject: RFR: Prefer to take AOT method from the SC queue faster
In-Reply-To: <UI6YxQPC4UNRak-EY7H1jrBRdaBpFKm1V7H05VMRbLI=.9e6a634b-b1f1-4136-80f6-dd1b9f47007b@github.com>
References: <UI6YxQPC4UNRak-EY7H1jrBRdaBpFKm1V7H05VMRbLI=.9e6a634b-b1f1-4136-80f6-dd1b9f47007b@github.com>
Message-ID: <OIOu9BRWF8LBLi-PmJOLAf0XtV76ZrRv_tbYXy0FVZ4=.22771685-56d0-42e8-b1c2-bbd91da8156b@github.com>

On Fri, 6 Sep 2024 19:41:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Probably WIP. Humor me for a second: why could not / should not we take the AOT task for "compilation" (installation, really) right away like this? I suspect when SC queues are overwhelmed with N elements, we keep walking the entire SC queue for no particular reason?
> 
> This improves javac benchmark considerably (look at both wall time and user time):
> 
> 
> # BEFORE
> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp JavacBenchApp.jar JavacBenchApp 50
>   Time (mean ? ?):     348.3 ms ?   2.8 ms    [User: 949.0 ms, System: 101.4 ms]
>   Range (min ? max):   344.0 ms ? 355.3 ms    100 runs
> 
> # AFTER
> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp JavacBenchApp.jar JavacBenchApp 50
>   Time (mean ? ?):     312.2 ms ?   2.6 ms    [User: 577.8 ms, System: 95.4 ms]
>   Range (min ? max):   307.1 ms ? 318.5 ms    100 runs

src/hotspot/share/compiler/compilationPolicy.cpp line 914:

> 912:       max_task = task;
> 913:       max_method = method;
> 914:       break;

I think we can just return `task` here.

We don't cache `CompLevel_full_profile` Level3 C1 compiled code and as result we do nothing in the rest of this method for AOT code.

We put SCC tasks on separate queues which will have only these tasks.

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/17#discussion_r1747775671

From kvn at openjdk.org  Fri Sep  6 22:27:06 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 6 Sep 2024 22:27:06 GMT
Subject: git: openjdk/leyden: premain: Rework rich PrintCompilation logs
Message-ID: <e6e0bb50-f3b4-475b-967f-987e44da63a7@openjdk.org>

Changeset: d7bd0ccc
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-09-06 22:26:04 +0000
URL:       https://git.openjdk.org/leyden/commit/d7bd0cccea97a9cee9810f58e07a5b2d0b474d08

Rework rich PrintCompilation logs

Reviewed-by: kvn

! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/compiler/compileTask.cpp
! src/hotspot/share/compiler/compileTask.hpp


From shade at openjdk.org  Fri Sep  6 22:29:20 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 6 Sep 2024 22:29:20 GMT
Subject: Integrated: Rework rich PrintCompilation logs
In-Reply-To: <zLhCmUJJNvTtr0OlHLVB-VhCd6PZJOrEk-Tj0BYnho0=.35fcaefe-4b14-492a-ab81-52dee3fef653@github.com>
References: <zLhCmUJJNvTtr0OlHLVB-VhCd6PZJOrEk-Tj0BYnho0=.35fcaefe-4b14-492a-ab81-52dee3fef653@github.com>
Message-ID: <AtObJLtT1K3QLwTENYfBk2Xq7Z8PNtgoF9lyrDKtwXw=.45fde32b-53f3-4045-8350-dbeaaf44c98c@github.com>

On Fri, 6 Sep 2024 18:49:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have been studying javac benchmark behavior, and current `PrintCompilation` logs are very useful to figure out how much time is spent in creation, queueing, work time for each task. Current logs are quite a bit confusing, though:
>  - The columns are misindented
>  - The precision is too low to capture short events: most of the times are zero
>  - Output seems to rely on "now" timestamp, which depends on _when_ we print
>  
> This PR reworks the logs to be more straightforward.
> 
> Example before:
> 
> 
>    S296 C0 Q229 3531      A  2       com.sun.tools.javac.parser.JavacParser::typeName (37 bytes)
>    S296 C0 Q245 2030      A  2       com.sun.tools.javac.tree.TreeInfo::innermostType (102 bytes)
>    S296 C0 Q0 4169         3       com.sun.tools.javac.comp.Flow$AliveAnalyzer$$Lambda/0x800000105::accept (12 bytes)
>    S296 C0 Q245 2042      A  2       com.sun.tools.javac.tree.JCTree$JCPrimitiveTypeTree::accept (9 bytes)
>    S296 C0 Q0 4170         3       com.sun.tools.javac.comp.Flow$AssignAnalyzer$$Lambda/0x800000108::accept (12 bytes)
>    S296 C0 Q0 4171         3       com.sun.tools.javac.comp.Flow$FlowAnalyzer$$Lambda/0x80000010a::accept (12 bytes)
>    S296 C0 Q245 2098      A  2       com.sun.tools.javac.code.Symbol$RecordComponent::getOriginalAnnos (24 bytes)
>    S296 C0 Q244 2348      A  2       com.sun.tools.javac.tree.TreeCopier::visitPrimitiveType (24 bytes)
>    S296 C0 Q244 2349      A  2       com.sun.tools.javac.tree.TreeCopier::visitPrimitiveType (7 bytes)
> 
> 
> Example after:
> 
> 
>     386    W0.0  Q313.7    C0.2   3524   !  A  2       com.sun.tools.javac.parser.JavacParser::literal (655 bytes)
>     386                           3858         3       java.util.stream.MatchOps$$Lambda/0x800000030::<init> (15 bytes)   made not entrant
>     386    W0.1                   2416      A  1       com.sun.tools.javac.comp.Infer$CheckInst::boundsToCheck (5 bytes)
>     386    W0.0    Q0.1    C0.2   4155         4       java.util.stream.MatchOps$$Lambda/0x800000030::<init> (15 bytes)
>     386    W0.1  Q332.7    C0.0   2416      A  1       com.sun.tools.javac.comp.Infer$CheckInst::boundsToCheck (5 bytes)
>     386    W0.2                   2902      A  2       com.sun.tools.javac.code.ClassFinder::classFileNotFound (13 bytes)
>     386    W0.2  Q327.9    C0.0   2902      A  2       com.sun.tools.javac.code.ClassFinder::classFileNotFound (13 bytes)
>     386    W0.0                   3527      A  2       com.sun.tools.javac.parser.JavacParser::parseExpression (6 bytes)
>     386    W0.0  Q314.2    C0...

This pull request has now been integrated.

Changeset: d7bd0ccc
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/leyden/commit/d7bd0cccea97a9cee9810f58e07a5b2d0b474d08
Stats:     40 lines in 3 files changed: 23 ins; 0 del; 17 mod

Rework rich PrintCompilation logs

Reviewed-by: kvn

-------------

PR: https://git.openjdk.org/leyden/pull/16

From shade at openjdk.org  Sat Sep  7 06:53:18 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Sat, 7 Sep 2024 06:53:18 GMT
Subject: RFR: Prefer to take AOT method from the SC queue faster
In-Reply-To: <OIOu9BRWF8LBLi-PmJOLAf0XtV76ZrRv_tbYXy0FVZ4=.22771685-56d0-42e8-b1c2-bbd91da8156b@github.com>
References: <UI6YxQPC4UNRak-EY7H1jrBRdaBpFKm1V7H05VMRbLI=.9e6a634b-b1f1-4136-80f6-dd1b9f47007b@github.com>
 <OIOu9BRWF8LBLi-PmJOLAf0XtV76ZrRv_tbYXy0FVZ4=.22771685-56d0-42e8-b1c2-bbd91da8156b@github.com>
Message-ID: <q2sgw8IZgB2cswLX_N0WwsxcT0PtULozpjoDGB4Mhxo=.ff3cdaf3-c137-49b2-8c40-6ac154410906@github.com>

On Fri, 6 Sep 2024 22:23:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Probably WIP. Humor me for a second: why could not / should not we take the AOT task for "compilation" (installation, really) right away like this? I suspect when SC queues are overwhelmed with N elements, we keep walking the entire SC queue for no particular reason?
>> 
>> This improves javac benchmark considerably (look at both wall time and user time):
>> 
>> 
>> # BEFORE
>> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp JavacBenchApp.jar JavacBenchApp 50
>>   Time (mean ? ?):     348.3 ms ?   2.8 ms    [User: 949.0 ms, System: 101.4 ms]
>>   Range (min ? max):   344.0 ms ? 355.3 ms    100 runs
>> 
>> # AFTER
>> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp JavacBenchApp.jar JavacBenchApp 50
>>   Time (mean ? ?):     312.2 ms ?   2.6 ms    [User: 577.8 ms, System: 95.4 ms]
>>   Range (min ? max):   307.1 ms ? 318.5 ms    100 runs
>
> src/hotspot/share/compiler/compilationPolicy.cpp line 914:
> 
>> 912:       max_task = task;
>> 913:       max_method = method;
>> 914:       break;
> 
> I think we can just return `task` here.
> 
> We don't cache `CompLevel_full_profile` Level3 C1 compiled code and as result we do nothing in the rest of this method for AOT code.
> 
> We put SCC tasks on separate queues which will have only these tasks.

Right, that makes sense. Since we want to get the SC tasks as soon as possible, it makes sense to shortcut hard. I'll do it in new commit.

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/17#discussion_r1747979871

From shade at openjdk.org  Sat Sep  7 06:59:33 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Sat, 7 Sep 2024 06:59:33 GMT
Subject: RFR: Prefer to take AOT method from the SC queue faster [v2]
In-Reply-To: <UI6YxQPC4UNRak-EY7H1jrBRdaBpFKm1V7H05VMRbLI=.9e6a634b-b1f1-4136-80f6-dd1b9f47007b@github.com>
References: <UI6YxQPC4UNRak-EY7H1jrBRdaBpFKm1V7H05VMRbLI=.9e6a634b-b1f1-4136-80f6-dd1b9f47007b@github.com>
Message-ID: <IUPwbUC1urM6AHJYmC9kDZkEKIdi4tSTifL2gZIKJjc=.9dffc665-57bb-4328-a3ef-ff922ef266b5@github.com>

> Probably WIP. Humor me for a second: why could not / should not we take the AOT task for "compilation" (installation, really) right away like this? I suspect when SC queues are overwhelmed with N elements, we keep walking the entire SC queue for no particular reason?
> 
> This improves javac benchmark considerably (look at both wall time and user time):
> 
> 
> # BEFORE
> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp JavacBenchApp.jar JavacBenchApp 50
>   Time (mean ? ?):     348.3 ms ?   2.8 ms    [User: 949.0 ms, System: 101.4 ms]
>   Range (min ? max):   344.0 ms ? 355.3 ms    100 runs
> 
> # AFTER
> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp JavacBenchApp.jar JavacBenchApp 50
>   Time (mean ? ?):     312.2 ms ?   2.6 ms    [User: 577.8 ms, System: 95.4 ms]
>   Range (min ? max):   307.1 ms ? 318.5 ms    100 runs

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Drop SCC check from comparator
 - Just return the SCC task right away
 - Merge branch 'premain' into shortcut-aot-tasks
 - Fix

-------------

Changes:
  - all: https://git.openjdk.org/leyden/pull/17/files
  - new: https://git.openjdk.org/leyden/pull/17/files/50ba10f4..c43c4516

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=leyden&pr=17&range=01
 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=17&range=00-01

  Stats: 50 lines in 4 files changed: 24 ins; 5 del; 21 mod
  Patch: https://git.openjdk.org/leyden/pull/17.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/17/head:pull/17

PR: https://git.openjdk.org/leyden/pull/17

From shade at openjdk.org  Sat Sep  7 06:59:33 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Sat, 7 Sep 2024 06:59:33 GMT
Subject: RFR: Prefer to take AOT method from the SC queue faster
In-Reply-To: <pQ4cnV9YC-_ZRBmxaAmwuSN1JMRTa2Rw2zFmNvsS3p4=.146fe2df-5ddc-4d1e-a112-2831df4a5902@github.com>
References: <UI6YxQPC4UNRak-EY7H1jrBRdaBpFKm1V7H05VMRbLI=.9e6a634b-b1f1-4136-80f6-dd1b9f47007b@github.com>
 <pQ4cnV9YC-_ZRBmxaAmwuSN1JMRTa2Rw2zFmNvsS3p4=.146fe2df-5ddc-4d1e-a112-2831df4a5902@github.com>
Message-ID: <AfsB4_djg6SG_Moy8CugBmQ-0rx_SD-iwkYqm6b9V2M=.f088ae74-41cc-4894-b46e-6ddfbe7f8bba@github.com>

On Fri, 6 Sep 2024 22:11:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Currently we do that in `compare_task`:
> https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/compiler/compilationPolicy.cpp#L1185

Aha! That is not efficient, since we are still walking the entire queue. I measured that task selection on 1K queue takes ~25us, which means for 2K queue (normal for javac workload) we loiter in this code for 50ms, delaying the AOT loading. This explains why this patch has such an effect.

I dropped the SCC checks from `compare_task` and replaced them with asserts, since we are not expecting SCC tasks in that comparator anymore. No need to check SCC for normal compilation queues, which might delay compilation a bit.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/17#issuecomment-2335095683

From kvn at openjdk.org  Sat Sep  7 17:31:21 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 7 Sep 2024 17:31:21 GMT
Subject: RFR: Prefer to take AOT method from the SC queue faster [v2]
In-Reply-To: <IUPwbUC1urM6AHJYmC9kDZkEKIdi4tSTifL2gZIKJjc=.9dffc665-57bb-4328-a3ef-ff922ef266b5@github.com>
References: <UI6YxQPC4UNRak-EY7H1jrBRdaBpFKm1V7H05VMRbLI=.9e6a634b-b1f1-4136-80f6-dd1b9f47007b@github.com>
 <IUPwbUC1urM6AHJYmC9kDZkEKIdi4tSTifL2gZIKJjc=.9dffc665-57bb-4328-a3ef-ff922ef266b5@github.com>
Message-ID: <mezr76I7UsOxzWlzzbBbLKVNA9pPyJudtJgwq-YAAaM=.4468058c-0ae7-42a2-a7e3-e56166a1250d@github.com>

On Sat, 7 Sep 2024 06:59:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Probably WIP. Humor me for a second: why could not / should not we take the AOT task for "compilation" (installation, really) right away like this? I suspect when SC queues are overwhelmed with N elements, we keep walking the entire SC queue for no particular reason?
>> 
>> This improves javac benchmark considerably (look at both wall time and user time):
>> 
>> 
>> # BEFORE
>> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp JavacBenchApp.jar JavacBenchApp 50
>>   Time (mean ? ?):     348.3 ms ?   2.8 ms    [User: 949.0 ms, System: 101.4 ms]
>>   Range (min ? max):   344.0 ms ? 355.3 ms    100 runs
>> 
>> # AFTER
>> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp JavacBenchApp.jar JavacBenchApp 50
>>   Time (mean ? ?):     312.2 ms ?   2.6 ms    [User: 577.8 ms, System: 95.4 ms]
>>   Range (min ? max):   307.1 ms ? 318.5 ms    100 runs
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Drop SCC check from comparator
>  - Just return the SCC task right away
>  - Merge branch 'premain' into shortcut-aot-tasks
>  - Fix

Good.

-------------

Marked as reviewed by kvn (Committer).

PR Review: https://git.openjdk.org/leyden/pull/17#pullrequestreview-2288166546

From shade at openjdk.org  Sat Sep  7 21:35:17 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Sat, 7 Sep 2024 21:35:17 GMT
Subject: RFR: Prefer to take AOT method from the SC queue faster [v2]
In-Reply-To: <IUPwbUC1urM6AHJYmC9kDZkEKIdi4tSTifL2gZIKJjc=.9dffc665-57bb-4328-a3ef-ff922ef266b5@github.com>
References: <UI6YxQPC4UNRak-EY7H1jrBRdaBpFKm1V7H05VMRbLI=.9e6a634b-b1f1-4136-80f6-dd1b9f47007b@github.com>
 <IUPwbUC1urM6AHJYmC9kDZkEKIdi4tSTifL2gZIKJjc=.9dffc665-57bb-4328-a3ef-ff922ef266b5@github.com>
Message-ID: <KFhvBh3yQQnxBLC-crviT0vbbu66xI62NeFEpDxTB7o=.0b378bfd-eb13-46c6-bfd3-42a64ad50640@github.com>

On Sat, 7 Sep 2024 06:59:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Probably WIP. Humor me for a second: why could not / should not we take the AOT task for "compilation" (installation, really) right away like this? I suspect when SC queues are overwhelmed with N elements, we keep walking the entire SC queue for no particular reason?
>> 
>> This improves javac benchmark considerably (look at both wall time and user time):
>> 
>> 
>> # BEFORE
>> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp JavacBenchApp.jar JavacBenchApp 50
>>   Time (mean ? ?):     348.3 ms ?   2.8 ms    [User: 949.0 ms, System: 101.4 ms]
>>   Range (min ? max):   344.0 ms ? 355.3 ms    100 runs
>> 
>> # AFTER
>> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp JavacBenchApp.jar JavacBenchApp 50
>>   Time (mean ? ?):     312.2 ms ?   2.6 ms    [User: 577.8 ms, System: 95.4 ms]
>>   Range (min ? max):   307.1 ms ? 318.5 ms    100 runs
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Drop SCC check from comparator
>  - Just return the SCC task right away
>  - Merge branch 'premain' into shortcut-aot-tasks
>  - Fix

Thanks!

-------------

PR Comment: https://git.openjdk.org/leyden/pull/17#issuecomment-2336457593

From duke at openjdk.org  Sat Sep  7 21:35:17 2024
From: duke at openjdk.org (duke)
Date: Sat, 7 Sep 2024 21:35:17 GMT
Subject: RFR: Prefer to take AOT method from the SC queue faster [v2]
In-Reply-To: <IUPwbUC1urM6AHJYmC9kDZkEKIdi4tSTifL2gZIKJjc=.9dffc665-57bb-4328-a3ef-ff922ef266b5@github.com>
References: <UI6YxQPC4UNRak-EY7H1jrBRdaBpFKm1V7H05VMRbLI=.9e6a634b-b1f1-4136-80f6-dd1b9f47007b@github.com>
 <IUPwbUC1urM6AHJYmC9kDZkEKIdi4tSTifL2gZIKJjc=.9dffc665-57bb-4328-a3ef-ff922ef266b5@github.com>
Message-ID: <Xpi-iczixkzAPmcMqT_hQpECmuTH2l1gekNmvWx2gyg=.f63d46df-5f3d-4547-8039-e5d648247582@github.com>

On Sat, 7 Sep 2024 06:59:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Probably WIP. Humor me for a second: why could not / should not we take the AOT task for "compilation" (installation, really) right away like this? I suspect when SC queues are overwhelmed with N elements, we keep walking the entire SC queue for no particular reason?
>> 
>> This improves javac benchmark considerably (look at both wall time and user time):
>> 
>> 
>> # BEFORE
>> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp JavacBenchApp.jar JavacBenchApp 50
>>   Time (mean ? ?):     348.3 ms ?   2.8 ms    [User: 949.0 ms, System: 101.4 ms]
>>   Range (min ? max):   344.0 ms ? 355.3 ms    100 runs
>> 
>> # AFTER
>> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp JavacBenchApp.jar JavacBenchApp 50
>>   Time (mean ? ?):     312.2 ms ?   2.6 ms    [User: 577.8 ms, System: 95.4 ms]
>>   Range (min ? max):   307.1 ms ? 318.5 ms    100 runs
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Drop SCC check from comparator
>  - Just return the SCC task right away
>  - Merge branch 'premain' into shortcut-aot-tasks
>  - Fix

@shipilev 
Your change (at version c43c45162b758853b123d5ca4e1f36a1d192b6f3) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/17#issuecomment-2336457968

From duke at openjdk.org  Sun Sep  8 00:45:22 2024
From: duke at openjdk.org (duke)
Date: Sun, 8 Sep 2024 00:45:22 GMT
Subject: git: openjdk/leyden: hermetic-java-runtime: 16 new changesets
Message-ID: <b573f880-f0c0-41cb-9c85-3052093a5949@openjdk.org>

Changeset: 9e0ccb8b
Branch: hermetic-java-runtime
Author:    Fei Yang <fyang at openjdk.org>
Date:      2024-09-06 02:01:43 +0000
URL:       https://git.openjdk.org/leyden/commit/9e0ccb8bbd01ffbac466288977a770dd09e357af

8339548: GHA: RISC-V: Use Debian snapshot archive for bootstrap

Reviewed-by: shade, erikj

! .github/workflows/build-cross-compile.yml

Changeset: 7db4d46c
Branch: hermetic-java-runtime
Author:    nelanbu <yagmur.eren at oracle.com>
Committer: Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-09-06 06:44:54 +0000
URL:       https://git.openjdk.org/leyden/commit/7db4d46c3904d1a6949f053e6fc5e971cd519088

8330159: [C2] Remove or clarify Compile::init_start

Reviewed-by: chagedorn, dlong

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

Changeset: a35fd386
Branch: hermetic-java-runtime
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-09-06 07:43:38 +0000
URL:       https://git.openjdk.org/leyden/commit/a35fd3861044bdb8ddae378cb666b3d2e549a8c8

8339368: Switch targets are not inflated in CodeModel if no StackMap

Reviewed-by: liach

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

Changeset: a1eebbdf
Branch: hermetic-java-runtime
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-06 11:42:50 +0000
URL:       https://git.openjdk.org/leyden/commit/a1eebbdf8a62b641b765bf4cec5066690c11a8e5

8339576: Speed up raw bytecode processing in ClassFile API

Co-authored-by: Shaojin Wen <swen at openjdk.org>
Reviewed-by: asotona, redestad

! src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java
! src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java
! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java
! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerificationBytecodes.java
! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java
! test/jdk/jdk/classfile/UtilTest.java
! test/micro/org/openjdk/bench/jdk/classfile/CodeAttributeTools.java

Changeset: febbd998
Branch: hermetic-java-runtime
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-09-06 12:01:01 +0000
URL:       https://git.openjdk.org/leyden/commit/febbd998ee72054353e816e9b7b588c9ea2c0500

8339168: Optimize ClassFile Util slotSize

Reviewed-by: liach, redestad

! src/java.base/share/classes/jdk/internal/classfile/impl/DirectMethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java

Changeset: 260908e1
Branch: hermetic-java-runtime
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-06 12:04:38 +0000
URL:       https://git.openjdk.org/leyden/commit/260908e16ece7a0a9e6f538273b27c677db4d296

8339592: Simplify and remove unused code in ObjectMethods.<clinit>

Reviewed-by: liach

! src/java.base/share/classes/java/lang/runtime/ObjectMethods.java

Changeset: cb00333d
Branch: hermetic-java-runtime
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-06 12:27:53 +0000
URL:       https://git.openjdk.org/leyden/commit/cb00333d6a47760cb2ab17e867ea8dab32289f98

8339640: Reduce construction overheads in StringConcatFactory$InlineHiddenClassStrategy

Reviewed-by: liach

! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java

Changeset: d2b36f09
Branch: hermetic-java-runtime
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-06 12:37:48 +0000
URL:       https://git.openjdk.org/leyden/commit/d2b36f09072e03370ee02b063fcc4a1f0e6cb2ee

8339642: Reduce overheads in InvokerBytecodeGenerator

Reviewed-by: liach

! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/LambdaForm.java

Changeset: 9ebc2ecb
Branch: hermetic-java-runtime
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-09-06 13:38:22 +0000
URL:       https://git.openjdk.org/leyden/commit/9ebc2ecbf613da3bcee1dd5e8920a26d5f6d6df7

8339317: Optimize ClassFile writeBuffer

Reviewed-by: redestad, liach

! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractAttributeMapper.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectClassBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java
! src/java.base/share/classes/jdk/internal/classfile/impl/UnboundAttribute.java

Changeset: 0df10bbd
Branch: hermetic-java-runtime
Author:    Andrew Dinn <adinn at openjdk.org>
Date:      2024-09-06 13:57:13 +0000
URL:       https://git.openjdk.org/leyden/commit/0df10bbd96df46f23a7f57e5b9455fea41b2b15b

8339466: Enumerate shared stubs and define static fields and names via declarations

Reviewed-by: kvn, fyang

! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/arm/sharedRuntime_arm.cpp
! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp
! src/hotspot/cpu/s390/sharedRuntime_s390.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/zero/sharedRuntime_zero.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/sharedRuntime.hpp
+ src/hotspot/share/runtime/stubDeclarations.hpp

Changeset: 5b72bbf9
Branch: hermetic-java-runtime
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-06 14:57:12 +0000
URL:       https://git.openjdk.org/leyden/commit/5b72bbf9d4a4c9c966a665c8d48e5f6c0dcdba1c

8339519: Remove size field from instructions

Reviewed-by: asotona

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

Changeset: 8e580ec5
Branch: hermetic-java-runtime
Author:    Jorn Vernee <jvernee at openjdk.org>
Date:      2024-09-06 17:32:34 +0000
URL:       https://git.openjdk.org/leyden/commit/8e580ec5382af1886e1bbf2fda3bce6416ced604

8338123: Linker crash when building a downcall handle with many arguments in x64

Reviewed-by: mcimadamore

! src/hotspot/cpu/x86/downcallLinker_x86_64.cpp
! test/jdk/java/foreign/largestub/TestLargeStub.java

Changeset: fbe26293
Branch: hermetic-java-runtime
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-09-06 18:37:29 +0000
URL:       https://git.openjdk.org/leyden/commit/fbe2629303bcee5855673b7e37d8c49f19dc9849

8339635: StringConcatFactory optimization for CompactStrings off

Reviewed-by: liach

! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java

Changeset: deeb09a6
Branch: hermetic-java-runtime
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2024-09-07 05:46:47 +0000
URL:       https://git.openjdk.org/leyden/commit/deeb09a640bf693ea130d1283fc010c22f0cf9db

8339307: jhsdb jstack could not trace FFM upcall frame

Reviewed-by: cjplummer, jvernee

! src/hotspot/share/code/codeBlob.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java
+ src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/UpcallStub.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java
+ test/hotspot/jtreg/serviceability/sa/LingeredAppWithFFMUpcall.java
+ test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackUpcall.java
+ test/hotspot/jtreg/serviceability/sa/libupcall.c

Changeset: f0e84b76
Branch: hermetic-java-runtime
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-09-07 22:20:37 +0000
URL:       https://git.openjdk.org/leyden/commit/f0e84b7617aebc421483f36bb7d0b14d0fc39616

8339703: Problem list serviceability/sa/TestJhsdbJstackUpcall.java for generational ZGC

Reviewed-by: dholmes

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

Changeset: 2e232b06
Branch: hermetic-java-runtime
Author:    Jiangli Zhou <jianglizhou at google.com>
Date:      2024-09-07 17:33:47 +0000
URL:       https://git.openjdk.org/leyden/commit/2e232b068d488a710bbf334829504d84e1c8ea4f

Merge branch 'master' into hermetic-java-runtime



From kvn at openjdk.org  Sun Sep  8 02:41:16 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 8 Sep 2024 02:41:16 GMT
Subject: git: openjdk/leyden: premain: Prefer to take AOT method from the SC
 queue faster
Message-ID: <915c723b-cd9b-466b-9b13-5a126675abe6@openjdk.org>

Changeset: 678b50d1
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-09-08 02:40:48 +0000
URL:       https://git.openjdk.org/leyden/commit/678b50d17a0eb3e0ac9d6476275753feecd1ec7b

Prefer to take AOT method from the SC queue faster

Reviewed-by: kvn

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


From shade at openjdk.org  Sun Sep  8 02:43:17 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Sun, 8 Sep 2024 02:43:17 GMT
Subject: Integrated: Prefer to take AOT method from the SC queue faster
In-Reply-To: <UI6YxQPC4UNRak-EY7H1jrBRdaBpFKm1V7H05VMRbLI=.9e6a634b-b1f1-4136-80f6-dd1b9f47007b@github.com>
References: <UI6YxQPC4UNRak-EY7H1jrBRdaBpFKm1V7H05VMRbLI=.9e6a634b-b1f1-4136-80f6-dd1b9f47007b@github.com>
Message-ID: <9MWMMd4UjDciCWjWWIp4SS2itk1dtPY3vMZU6cYTfFI=.8abb565b-cf32-4efe-bbf5-18920d1a3747@github.com>

On Fri, 6 Sep 2024 19:41:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Probably WIP. Humor me for a second: why could not / should not we take the AOT task for "compilation" (installation, really) right away like this? I suspect when SC queues are overwhelmed with N elements, we keep walking the entire SC queue for no particular reason?
> 
> This improves javac benchmark considerably (look at both wall time and user time):
> 
> 
> # BEFORE
> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp JavacBenchApp.jar JavacBenchApp 50
>   Time (mean ? ?):     348.3 ms ?   2.8 ms    [User: 949.0 ms, System: 101.4 ms]
>   Range (min ? max):   344.0 ms ? 355.3 ms    100 runs
> 
> # AFTER
> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -cp JavacBenchApp.jar JavacBenchApp 50
>   Time (mean ? ?):     312.2 ms ?   2.6 ms    [User: 577.8 ms, System: 95.4 ms]
>   Range (min ? max):   307.1 ms ? 318.5 ms    100 runs

This pull request has now been integrated.

Changeset: 678b50d1
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/leyden/commit/678b50d17a0eb3e0ac9d6476275753feecd1ec7b
Stats:     9 lines in 1 file changed: 5 ins; 3 del; 1 mod

Prefer to take AOT method from the SC queue faster

Reviewed-by: kvn

-------------

PR: https://git.openjdk.org/leyden/pull/17

From duke at openjdk.org  Sun Sep  8 19:33:08 2024
From: duke at openjdk.org (duke)
Date: Sun, 8 Sep 2024 19:33:08 GMT
Subject: git: openjdk/leyden: premain: Improve incapsulation
Message-ID: <0a400c31-7d5e-498a-9c4a-e9cb32a737b0@openjdk.org>

Changeset: 5fd814c0
Branch: premain
Author:    Igor Veresov <igor.veresov at oracle.com>
Date:      2024-09-08 12:29:20 +0000
URL:       https://git.openjdk.org/leyden/commit/5fd814c0f805f63d7920d3da34b0c6b7b5381198

Improve incapsulation

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


From shade at openjdk.org  Mon Sep  9 07:52:20 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 9 Sep 2024 07:52:20 GMT
Subject: RFR: Mark Leyden tests that require artifacts with "external-dep"
In-Reply-To: <cVKzHMQ4gidQfPcSmAb5fH7RLWapBqQgWKFLUfBx8Oc=.67021a71-2ea4-4ca0-832a-f2e4c5ba7f0a@github.com>
References: <cVKzHMQ4gidQfPcSmAb5fH7RLWapBqQgWKFLUfBx8Oc=.67021a71-2ea4-4ca0-832a-f2e4c5ba7f0a@github.com>
Message-ID: <qDB28pn7reg6nQEIuSdPM5Vciw8jH9dLQDbwaY2MqqE=.8fc81e48-9008-4a10-aae5-25dad030dd12@github.com>

On Thu, 5 Sep 2024 17:38:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8323717](https://bugs.openjdk.org/browse/JDK-8323717) added a new keyword that marks tests that require external artifacts. This allows skipping the tests that would definitely fail without artifact resolution. This PR marks the new Leyden tests.
> 
> Tested with:
> 
> 
> $ JTREG_KEYWORDS='!external-dep' CONF=linux-x86_64-server-fastdebug make test TEST=runtime/cds/appcds
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg/runtime/cds/appcds         288   288     0     0   
> ==============================

This should be an easy infrastructure fix, please take a look, @iklam.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/14#issuecomment-2337378219

From shade at openjdk.org  Mon Sep  9 11:10:57 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 9 Sep 2024 11:10:57 GMT
Subject: RFR: Reformat internal profiling stats
Message-ID: <BWF3jak3Q7K_pwiHDphZWkLr8SZAd73JcwKvuPprvYY=.c281cf2b-ffa6-46d3-972a-bf97ed119e33@github.com>

For HelloWorld/javac workloads, the current output resolution in milliseconds is not enough, we better off printing microseconds. Plus, indenting is not agreeing in interpreter/C1/C2 outputs, fixed that as well.

-------------

Commit messages:
 - Reformat internal profiling stats

Changes: https://git.openjdk.org/leyden/pull/18/files
  Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=18&range=00
  Stats: 80 lines in 15 files changed: 17 ins; 0 del; 63 mod
  Patch: https://git.openjdk.org/leyden/pull/18.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/18/head:pull/18

PR: https://git.openjdk.org/leyden/pull/18

From shade at openjdk.org  Mon Sep  9 17:37:17 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 9 Sep 2024 17:37:17 GMT
Subject: RFR: Reformat internal profiling stats [v2]
In-Reply-To: <BWF3jak3Q7K_pwiHDphZWkLr8SZAd73JcwKvuPprvYY=.c281cf2b-ffa6-46d3-972a-bf97ed119e33@github.com>
References: <BWF3jak3Q7K_pwiHDphZWkLr8SZAd73JcwKvuPprvYY=.c281cf2b-ffa6-46d3-972a-bf97ed119e33@github.com>
Message-ID: <C0bEW0lvaGa8zdqAbPNTIwbi_N3BYkGQ9esQukmD3VY=.852a52f7-48f3-4568-86e5-a94194ef3a1a@github.com>

> For HelloWorld/javac workloads, the current output resolution in milliseconds is not enough, we better off printing microseconds. Plus, indenting is not agreeing in interpreter/C1/C2 outputs, fixed that as well.

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Whitespace

-------------

Changes:
  - all: https://git.openjdk.org/leyden/pull/18/files
  - new: https://git.openjdk.org/leyden/pull/18/files/5e1aaa71..3e312405

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=leyden&pr=18&range=01
 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=18&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/leyden/pull/18.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/18/head:pull/18

PR: https://git.openjdk.org/leyden/pull/18

From iklam at openjdk.org  Mon Sep  9 19:44:22 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 9 Sep 2024 19:44:22 GMT
Subject: RFR: Mark Leyden tests that require artifacts with "external-dep"
In-Reply-To: <cVKzHMQ4gidQfPcSmAb5fH7RLWapBqQgWKFLUfBx8Oc=.67021a71-2ea4-4ca0-832a-f2e4c5ba7f0a@github.com>
References: <cVKzHMQ4gidQfPcSmAb5fH7RLWapBqQgWKFLUfBx8Oc=.67021a71-2ea4-4ca0-832a-f2e4c5ba7f0a@github.com>
Message-ID: <x2XL_xt3lqsEX_pnMrzv04jCpW--JQ90QzorVWVzUvw=.53fd9787-1931-4e1f-8d22-2ce5227782c9@github.com>

On Thu, 5 Sep 2024 17:38:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8323717](https://bugs.openjdk.org/browse/JDK-8323717) added a new keyword that marks tests that require external artifacts. This allows skipping the tests that would definitely fail without artifact resolution. This PR marks the new Leyden tests.
> 
> Tested with:
> 
> 
> $ JTREG_KEYWORDS='!external-dep' CONF=linux-x86_64-server-fastdebug make test TEST=runtime/cds/appcds
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg/runtime/cds/appcds         288   288     0     0   
> ==============================

LGTM. I didn't know of such a key (used by hotspot/jtreg/applications/scimark/Scimark.java, etc). Thanks for fixing it.

-------------

Marked as reviewed by iklam (Committer).

PR Review: https://git.openjdk.org/leyden/pull/14#pullrequestreview-2290802609

From Jeffrey.A.Boyce at Carrier.com  Mon Sep  9 20:16:40 2024
From: Jeffrey.A.Boyce at Carrier.com (Boyce, Jeffrey)
Date: Mon, 9 Sep 2024 20:16:40 +0000
Subject: "incompatible property" error when using --add-modules, --add-opens, 
 --add-exports, etc.
Message-ID: <MW4PR06MB7865FE42B22B629B6D46F4F4BB992@MW4PR06MB7865.namprd06.prod.outlook.com>

Hello,

I am attempting to evaluate performance improvements afforded by the Leyden CDS enhancements for an embedded application running on aarch64.  The application makes extensive use of the --add-modules, --add-opens, and --add-exports command line arguments.  However, it appears that these arguments are incompatible with the -XX:CacheDataStore option, as their use results in errors similar to the following:

[0.004s][warning][cds] optimized module handling/full module graph: disabled due to incompatible property: jdk.module.addopens=java.base/java.nio=org.apache.tomcat.embed.core
Error occurred during initialization of VM
CacheDataStore cannot be created because AOTClassLinking is enabled but full module graph is disabled

Is this the expected behavior?  If yes, is there a workaround or a plan to support these options in the future?


Thanks,

Jeff Boyce



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

From ioi.lam at oracle.com  Tue Sep 10 06:51:30 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Mon, 9 Sep 2024 23:51:30 -0700
Subject: "incompatible property" error when using --add-modules,
 --add-opens, --add-exports, etc.
In-Reply-To: <MW4PR06MB7865FE42B22B629B6D46F4F4BB992@MW4PR06MB7865.namprd06.prod.outlook.com>
References: <MW4PR06MB7865FE42B22B629B6D46F4F4BB992@MW4PR06MB7865.namprd06.prod.outlook.com>
Message-ID: <c92600b1-1ec7-47ce-a2c0-4e78357b94c9@oracle.com>

Yes, this is expected behavior.

A short explanation: the Leyden optimizations depends on 
-XX:+AOTClassLinking, which requires that all classes loaded during the 
training run are visible during the production run.

For example, if --add-module is specified differently during the two 
runs, class A could be loading in the training run and become inlined by 
AOT-compiled methods. At runtime, if a different set of --add-modules is 
used, class A may not be loadable, and we would have to invalidate the 
corresponding optimizations.

Doing such checks correctly is complicated. Today, we have a very simple 
check -- (a) the full module graph must be archived during the training 
run, and (b) the full module graph must be loaded from the AOT cache 
during the production run. This way we know the exact set of modules are 
used in the two runs so the same set of classes are visible.

Currently, we allow the full module graph to be archived only with a 
restricted set of options -- see 
ModuleBootstrap::canUseArchivedBootLayer(). We are working to relax the 
restrictions (see https://bugs.openjdk.org/browse/JDK-8328313 -- 
Archived module graph should allow identical --module-path to be 
specified during dump time and run time).

Supporting --add-modules, --add-opens, and --add-exports may require 
more work. For --add-opens and --add-exports, I'd to understand why they 
are being used. Maybe they are for accessing JDK internals that 
otherwise shouldn't really be touched?

Thanks

- Ioi


On 9/9/24 1:16 PM, Boyce, Jeffrey wrote:
> Hello,
> I am attempting to evaluate performance improvements afforded by the 
> Leyden CDS enhancements for an embedded application running on 
> aarch64.? The application makes extensive use of the --add-modules, 
> --add-opens, and --add-exports command line arguments. However, it 
> appears that these arguments are incompatible with the 
> -XX:CacheDataStore option, as their use results in errors similar to 
> the following:
> [0.004s][warning][cds] optimized module handling/full module graph: 
> disabled due to incompatible property: 
> jdk.module.addopens=java.base/java.nio=org.apache.tomcat.embed.core
> Error occurred during initialization of VM
> CacheDataStore cannot be created because AOTClassLinking is enabled 
> but full module graph is disabled
> Is this the expected behavior?? If yes, is there a workaround or a 
> plan to support these options in the future?
> Thanks,
> Jeff Boyce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240909/6913a64b/attachment.htm>

From shade at openjdk.org  Tue Sep 10 08:07:21 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 10 Sep 2024 08:07:21 GMT
Subject: RFR: Mark Leyden tests that require artifacts with "external-dep"
In-Reply-To: <cVKzHMQ4gidQfPcSmAb5fH7RLWapBqQgWKFLUfBx8Oc=.67021a71-2ea4-4ca0-832a-f2e4c5ba7f0a@github.com>
References: <cVKzHMQ4gidQfPcSmAb5fH7RLWapBqQgWKFLUfBx8Oc=.67021a71-2ea4-4ca0-832a-f2e4c5ba7f0a@github.com>
Message-ID: <c5m3l8V7SpkBERox4cloWbqPjw9ySkDVcY5uJvdgBXg=.d78a5480-7b1f-4d17-9bcf-4ae09fa0ba28@github.com>

On Thu, 5 Sep 2024 17:38:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8323717](https://bugs.openjdk.org/browse/JDK-8323717) added a new keyword that marks tests that require external artifacts. This allows skipping the tests that would definitely fail without artifact resolution. This PR marks the new Leyden tests.
> 
> Tested with:
> 
> 
> $ JTREG_KEYWORDS='!external-dep' CONF=linux-x86_64-server-fastdebug make test TEST=runtime/cds/appcds
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg/runtime/cds/appcds         288   288     0     0   
> ==============================

Yes, I added it a while ago to avoid these kinds of failures :)

-------------

PR Comment: https://git.openjdk.org/leyden/pull/14#issuecomment-2339950399

From duke at openjdk.org  Tue Sep 10 08:07:21 2024
From: duke at openjdk.org (duke)
Date: Tue, 10 Sep 2024 08:07:21 GMT
Subject: RFR: Mark Leyden tests that require artifacts with "external-dep"
In-Reply-To: <cVKzHMQ4gidQfPcSmAb5fH7RLWapBqQgWKFLUfBx8Oc=.67021a71-2ea4-4ca0-832a-f2e4c5ba7f0a@github.com>
References: <cVKzHMQ4gidQfPcSmAb5fH7RLWapBqQgWKFLUfBx8Oc=.67021a71-2ea4-4ca0-832a-f2e4c5ba7f0a@github.com>
Message-ID: <7NqO5Nf0gTY3p3ji3nhUPGjOcVDb_ZclJzM--4k0odQ=.2d173867-b15d-4633-99e6-7ae8aca736f2@github.com>

On Thu, 5 Sep 2024 17:38:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8323717](https://bugs.openjdk.org/browse/JDK-8323717) added a new keyword that marks tests that require external artifacts. This allows skipping the tests that would definitely fail without artifact resolution. This PR marks the new Leyden tests.
> 
> Tested with:
> 
> 
> $ JTREG_KEYWORDS='!external-dep' CONF=linux-x86_64-server-fastdebug make test TEST=runtime/cds/appcds
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg/runtime/cds/appcds         288   288     0     0   
> ==============================

@shipilev 
Your change (at version 1a8cbdf74dff90245e9ce82ce5beff0b91bff1a6) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/14#issuecomment-2339953927

From iklam at openjdk.org  Tue Sep 10 09:18:03 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 10 Sep 2024 09:18:03 GMT
Subject: git: openjdk/leyden: premain: Mark Leyden tests that require artifacts
 with "external-dep"
Message-ID: <9c7dc4f0-a750-45c2-b118-19653b8689f4@openjdk.org>

Changeset: d23b9f2d
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: Ioi Lam <iklam at openjdk.org>
Date:      2024-09-10 09:17:33 +0000
URL:       https://git.openjdk.org/leyden/commit/d23b9f2d5e3523cc547337da59327ed86a6057a3

Mark Leyden tests that require artifacts with "external-dep"

Reviewed-by: iklam

! test/hotspot/jtreg/runtime/cds/appcds/applications/HelidonQuickStartSE.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/MicronautFirstApp.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/QuarkusGettingStarted.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/SpringPetClinic.java


From shade at openjdk.org  Tue Sep 10 09:20:30 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 10 Sep 2024 09:20:30 GMT
Subject: Integrated: Mark Leyden tests that require artifacts with
 "external-dep"
In-Reply-To: <cVKzHMQ4gidQfPcSmAb5fH7RLWapBqQgWKFLUfBx8Oc=.67021a71-2ea4-4ca0-832a-f2e4c5ba7f0a@github.com>
References: <cVKzHMQ4gidQfPcSmAb5fH7RLWapBqQgWKFLUfBx8Oc=.67021a71-2ea4-4ca0-832a-f2e4c5ba7f0a@github.com>
Message-ID: <XwD_cUTlOHQwCvRSiY2PXOgM9Ve0CWzLznLEPekWn8o=.db6b1572-9581-40a0-be4c-6372ebebdd85@github.com>

On Thu, 5 Sep 2024 17:38:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8323717](https://bugs.openjdk.org/browse/JDK-8323717) added a new keyword that marks tests that require external artifacts. This allows skipping the tests that would definitely fail without artifact resolution. This PR marks the new Leyden tests.
> 
> Tested with:
> 
> 
> $ JTREG_KEYWORDS='!external-dep' CONF=linux-x86_64-server-fastdebug make test TEST=runtime/cds/appcds
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg/runtime/cds/appcds         288   288     0     0   
> ==============================

This pull request has now been integrated.

Changeset: d23b9f2d
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/leyden/commit/d23b9f2d5e3523cc547337da59327ed86a6057a3
Stats:     16 lines in 4 files changed: 16 ins; 0 del; 0 mod

Mark Leyden tests that require artifacts with "external-dep"

Reviewed-by: iklam

-------------

PR: https://git.openjdk.org/leyden/pull/14

From adinn at redhat.com  Wed Sep 11 09:39:20 2024
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 11 Sep 2024 10:39:20 +0100
Subject: premain: Crash in Infinispan server code caused by NPE under
 MethodHandleNative::linkDynamicConstant
Message-ID: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>

[n.b. resent using correct email id]

A crash due to an NPE was observed in the Infinispan (Data Grid) server 
app when deployed using the Leyden EA. The crash still manifests with 
the latest premain code. The crash happens when an application call 
which employs a method reference as argument enters 
MethodHandleNative::linkDynamicConstant().

         putMakedPasswordImplementations(this::putService, this);

Debugging shows that the call to linkDynamicConstant() returns null.

A simple reproducer for the problem is available as a maven project on 
github:

   https://github.com/tristantarrant/elytron-leyden

The ReadMe provides an explanation of how to reproduce the problem. I 
did so and the debugged to find out some of the details of what is 
happening (see below) but did not fully clarify the problem. Help from 
someone more conversant with the ins and outs of method handle 
bootstraps in premain would be welcome. Details follow.

regards,


Andrew Dinn
-----------

I downloaded the git repo and attached the Java sources using Maven command

   $ mvn dependency:sources

Having manifested the crash by following the instructions in the README 
I reran the leyden JVM under gdb using the following commands to enable 
Java debugging

$ gdb ${LEYDEN_HOME}/bin/java
(gdb) cd /path/to/mvn/project
(gdb) run 
-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005 
-classpath 
/home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/2.5.1.Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar 
-XX:CacheDataStore=elytron.aot com.redhat.leyden.Main

The problem manifests at WildflyElytronBaseProvider.java:107 in method 
WildflyElytronBaseProvider::putPasswordImplementations() at a call to 
method putMakedPasswordImplementations:

         . . .
         putService(new Service(this, PASSWORD_FACTORY_TYPE, 
"otp-sha384", 
"org.wildfly.security.password.impl.PasswordFactorySpiImpl", emptyList, 
emptyMap));
         putService(new Service(this, PASSWORD_FACTORY_TYPE, 
"otp-sha512", 
"org.wildfly.security.password.impl.PasswordFactorySpiImpl", emptyList, 
emptyMap));
         putMakedPasswordImplementations(this::putService, this); <== 
NPE here
     }

The source code for this method can be found in the following source jar


${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar

(where M2_REPO will normally be ~/.m2/repository)

A step at this point entered MethodHandleNative::linkDynamicConstant 
which in turn entered into ConstantBootstraps.makeConstant(). The caller 
Class at this point is a lambda class which prints as 
org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c

Several steps further the code enters BootstrapMethodInvoker::invoke 
(below the app method call but via 3 hidden frames) with bootstrapMethod 
bound to a DirectMethodHandle. After several more steps this enters 
DirectMethodHandle$Holder.invokeStatic which in turn calls 
MethodHandles::classData(Lookup,String,Class).

At this point caller is a MethodHandleLookup for the lambda class 
Lambda/0x800000000c mentioned above. The following call

          Object classdata = classData(caller.lookupClass());

returns null to DirectMethodHandle$Holder.invokeStatic which pops the 
same result back out to BootstrapMethodInvoker::invoke at line 90

                 if (type instanceof Class<?> c) {
                     result = bootstrapMethod.invoke(caller, name, c); 
<== null

This null result pops back out as the value for the call to 
BootstrapMethodInvoker.invoke(), ConstantBootstraps.makeConstant() and 
MethodHandleNative::linkDynamicConstant().


From adinn at redhat.com  Wed Sep 11 10:03:12 2024
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 11 Sep 2024 11:03:12 +0100
Subject: premain: Crash in Infinispan server code caused by NPE under
 MethodHandleNative::linkDynamicConstant
In-Reply-To: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
References: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
Message-ID: <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>

Oops, sorry, I debugged this a few days ago! Correction to a few details:

On 11/09/2024 10:39, Andrew Dinn wrote:
> A crash due to an NPE was observed in the Infinispan (Data Grid) server 
> app when deployed using the Leyden EA. The crash still manifests with 
> the latest premain code. The crash happens below an application call 
> which employs a method reference as argument
> 
>  ??????? putMakedPasswordImplementations(this::putService, this);

The called method in turn calls consumer.accept

             consumer.accept(new Service(provider, 
PASSWORD_FACTORY_TYPE, algorithm, 
"org.wildfly.security.password.impl.PasswordFactorySpiImpl", emptyList, 
emptyMap));

which enters enters MethodHandleNative::linkDynamicConstant()

> Debugging shows that the call to linkDynamicConstant() returns null.
> 
> A simple reproducer for the problem is available as a maven project on 
> github:
> 
>  ? https://github.com/tristantarrant/elytron-leyden
> 
> The ReadMe provides an explanation of how to reproduce the problem. I 
> did so and the debugged to find out some of the details of what is 
> happening (see below) but did not fully clarify the problem. Help from 
> someone more conversant with the ins and outs of method handle 
> bootstraps in premain would be welcome. Details follow.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> 
> I downloaded the git repo and attached the Java sources using Maven command
> 
>  ? $ mvn dependency:sources
> 
> Having manifested the crash by following the instructions in the README 
> I reran the leyden JVM under gdb using the following commands to enable 
> Java debugging
> 
> $ gdb ${LEYDEN_HOME}/bin/java
> (gdb) cd /path/to/mvn/project
> (gdb) run 
> -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005 
> -classpath 
> /home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/2.5.1.Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar -XX:CacheDataStore=elytron.aot com.redhat.leyden.Main
> 
> The problem manifests at WildflyElytronBaseProvider.java:112 in method 
> WildflyElytronBaseProvider::putMakedPasswordImplementations

     static void putMakedPasswordImplementations(Consumer<Service> 
consumer, Provider provider) {
         for (String algorithm : MASKED_ALGORITHMS) {
             consumer.accept(new Service(provider, 
PASSWORD_FACTORY_TYPE, algorithm, 
"org.wildfly.security.password.impl.PasswordFactorySpiImpl", emptyList, 
emptyMap)); <== NPE under this call
         }


> The source code for this method can be found in the following source jar
> 
> 
> ${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar
> 
> (where M2_REPO will normally be ~/.m2/repository)
> 
> Stepping into accept eventually enters MethodHandleNative::linkDynamicConstant 
> which in turn enters into ConstantBootstraps.makeConstant(). The caller 
> Class at this point is a lambda class which prints as 
> org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c
> 
> Several steps further the code enters BootstrapMethodInvoker::invoke 
> (below the app method call but via 3 hidden frames) with bootstrapMethod 
> bound to a DirectMethodHandle. After several more steps this enters 
> DirectMethodHandle$Holder.invokeStatic which in turn calls 
> MethodHandles::classData(Lookup,String,Class).
> 
> At this point caller is a MethodHandleLookup for the lambda class 
> Lambda/0x800000000c mentioned above. The following call
> 
>  ???????? Object classdata = classData(caller.lookupClass());
> 
> returns null to DirectMethodHandle$Holder.invokeStatic which pops the 
> same result back out to BootstrapMethodInvoker::invoke at line 90
> 
>  ??????????????? if (type instanceof Class<?> c) {
>  ??????????????????? result = bootstrapMethod.invoke(caller, name, c); 
> <== null
> 
> This null result pops back out as the value for the call to 
> BootstrapMethodInvoker.invoke(), ConstantBootstraps.makeConstant() and 
> MethodHandleNative::linkDynamicConstant().
> 


From sebastien.deleuze at broadcom.com  Wed Sep 11 10:50:43 2024
From: sebastien.deleuze at broadcom.com (Sebastien Deleuze)
Date: Wed, 11 Sep 2024 12:50:43 +0200
Subject: premain: CGLIB error during the training run with Petclinic
Message-ID: <CAG5jep_f8Ne8wRBEfD9hHB7TzLB-Axip6Yrnc6rz0SobgALOZw@mail.gmail.com>

Hi,

I may have hit a premain bug using the latest
https://github.com/openjdk/leyden/tree/premain that triggers a CGLIB error
during the training run with Petclinic, and am looking for feedback.

The premain branch of
https://github.com/sdeleuze/petclinic-efficient-container currently
performs a training run of Petclinic where the application exits early
since -Dspring.context.exit=onRefresh is set, no workload is applied, the
application then starts again in the production and run faster as expected.
All good.

In the premain-training-run branch, I directly start Petclinic with
-XX:CacheDataStore=/tmp/application.cds in order to have the opportunity to
apply some workload to exercise the warm-up improvement capabilities later
in the production run.

On simple pages like http://localhost:8080/, it works as expected, but when
I try more complex pages like http://localhost:8080/owners, It get the
following error:

Request processing failed: java.lang.RuntimeException:
java.lang.IllegalStateException:
org.springframework.cglib.core.ReflectUtils$2: No compatible defineClass
mechanism detected: JVM should be started with
--add-opens=java.base/java.lang=ALL-UNNAMED for ClassLoader.defineClass to
be accessible. On the module path, you may not be able to define this
CGLIB-generated class at all.] with root cause
java.lang.reflect.InaccessibleObjectException: Unable to make protected
final java.lang.Class
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
throws java.lang.ClassFormatError accessible: module java.base does not
"opens java.lang" to unnamed module @d5c1bc
at
java.base/java.lang.reflect.AccessibleObject.throwInaccessibleObjectException(AccessibleObject.java:388)
~[na:na]
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:364)
~[na:na]
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:312)
~[na:na]
at
java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:190)
~[na:na]
at java.base/java.lang.reflect.Method.setAccessible(Method.java:184)
~[na:na]
at
org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:505)
~[spring-core-6.2.0-M7.jar:6.2.0-M7]

This application does not involve JPMS, it is just a regular Spring Boot
application. If I send more requests to the same endpoint, I see the
following error:

java.lang.VerifyError: Bad local variable type
Exception Details:
  Location:

org/springframework/samples/petclinic/owner/Owner_Accessor_82dqis.getProperty(Lorg/springframework/data/mapping/PersistentProperty;)Ljava/lang/Object;
@83: aload_2
  Reason:
    Type top (current frame, locals[2]) is not assignable to reference type
  Current Frame:
    bci: @83
    flags: { }
    locals: {
'org/springframework/samples/petclinic/owner/Owner_Accessor_82dqis',
'org/springframework/data/mapping/PersistentProperty' }
    stack: { 'java/lang/invoke/MethodHandle' }

To summarize, what I observe in my tests:
 - http://localhost:8080/owners without
-XX:CacheDataStore=/tmp/application.cds works
 - http://localhost:8080/owners with
-XX:CacheDataStore=/tmp/application.cds with an existing
/tmp/application.cds file works
 - http://localhost:8080/owners with
-XX:CacheDataStore=/tmp/application.cds with no existing
/tmp/application.cds file fails with the error mentioned above

Any thoughts?

Best regards,
S?bastien Deleuze

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240911/88b4d8c3/attachment.htm>

From alan.bateman at oracle.com  Wed Sep 11 11:18:29 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Sep 2024 12:18:29 +0100
Subject: premain: CGLIB error during the training run with Petclinic
In-Reply-To: <CAG5jep_f8Ne8wRBEfD9hHB7TzLB-Axip6Yrnc6rz0SobgALOZw@mail.gmail.com>
References: <CAG5jep_f8Ne8wRBEfD9hHB7TzLB-Axip6Yrnc6rz0SobgALOZw@mail.gmail.com>
Message-ID: <a8fd083c-4731-446e-9117-9898e8fe9fef@oracle.com>


On 11/09/2024 11:50, Sebastien Deleuze wrote:
> :
>
> Request processing failed: java.lang.RuntimeException: 
> java.lang.IllegalStateException: 
> org.springframework.cglib.core.ReflectUtils$2: No compatible 
> defineClass mechanism detected: JVM should be started with 
> --add-opens=java.base/java.lang=ALL-UNNAMED for 
> ClassLoader.defineClass to be accessible. On the module path, you may 
> not be able to define this CGLIB-generated class at all.] with root cause
> java.lang.reflect.InaccessibleObjectException: Unable to make 
> protected final java.lang.Class 
> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) 
> throws java.lang.ClassFormatError accessible: module java.base does 
> not "opens java.lang" to unnamed module @d5c1bc
> at 
> java.base/java.lang.reflect.AccessibleObject.throwInaccessibleObjectException(AccessibleObject.java:388) 
> ~[na:na]
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:364) 
> ~[na:na]
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:312) 
> ~[na:na]
> at 
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:190) 
> ~[na:na]
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:184) 
> ~[na:na]
> at 
> org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:505) 
> ~[spring-core-6.2.0-M7.jar:6.2.0-M7]

Are you saying that it "works" without --add-opens (and without 
-XX:CacheDataStore)?

I wonder if this library that has more than one way to inject classes, 
something fails, and it falls back to trying setAccessible as it worked 
in older JDK releases?

In any case, it is surprising to see this in 2024. Lookup.defineClass, 
and later Lookup.defineHiddenClass, are there for the frameworks to 
inject a proxy/other classes into same runtime package as a class that 
the framework is given access to.

I can't tell if this is related to the VerifyError.

-Alan

From alan.bateman at oracle.com  Wed Sep 11 12:50:44 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Sep 2024 13:50:44 +0100
Subject: premain: CGLIB error during the training run with Petclinic
In-Reply-To: <CAG5jep--vGCe--6FeOTiG_m4Ye+3JtHYBTfQA5mygDjPMYQsdg@mail.gmail.com>
References: <CAG5jep_f8Ne8wRBEfD9hHB7TzLB-Axip6Yrnc6rz0SobgALOZw@mail.gmail.com>
 <a8fd083c-4731-446e-9117-9898e8fe9fef@oracle.com>
 <CAG5jep--vGCe--6FeOTiG_m4Ye+3JtHYBTfQA5mygDjPMYQsdg@mail.gmail.com>
Message-ID: <4c7c879e-1488-41a8-a8e0-97d9f1379687@oracle.com>

On 11/09/2024 13:16, Sebastien Deleuze wrote:
> Yes, it works?without --add-opens and without -XX:CacheDataStore, in 
> all my use cases I never set --add-opens explicitly.
>
> There are various fallback?paths, and potentially the original 
> exception is hidden, so let me have a deeper look by comparing broken 
> and successful code paths.
> I will share more details in an upcoming email.
>
Maybe running with -Xlog:exceptions might reveal something.

-Alan

From sebastien.deleuze at broadcom.com  Wed Sep 11 13:02:22 2024
From: sebastien.deleuze at broadcom.com (Sebastien Deleuze)
Date: Wed, 11 Sep 2024 15:02:22 +0200
Subject: premain: CGLIB error during the training run with Petclinic
In-Reply-To: <4c7c879e-1488-41a8-a8e0-97d9f1379687@oracle.com>
References: <CAG5jep_f8Ne8wRBEfD9hHB7TzLB-Axip6Yrnc6rz0SobgALOZw@mail.gmail.com>
 <a8fd083c-4731-446e-9117-9898e8fe9fef@oracle.com>
 <CAG5jep--vGCe--6FeOTiG_m4Ye+3JtHYBTfQA5mygDjPMYQsdg@mail.gmail.com>
 <4c7c879e-1488-41a8-a8e0-97d9f1379687@oracle.com>
Message-ID: <CAG5jep8kCfuFELbN3T=aZds3=UvMCWL64LrD=yPd58KYJXHaPA@mail.gmail.com>

After adding more logging, I can confirm the original exception when
-XX:CacheDataStore is set with no existing CDS file is thrown by
MethodHandles.Lookup#defineClass and is similar to the second one I
reported.
This is a class that Spring Data generates during runtime.

java.lang.VerifyError: Bad local variable type
Exception Details:
  Location:

org/springframework/samples/petclinic/owner/Owner_Accessor_yw4ckn.getProperty(Lorg/springframework/data/mapping/PersistentProperty;)Ljava/lang/Object;
@83: aload_2
  Reason:
    Type top (current frame, locals[2]) is not assignable to reference type
  Current Frame:
    bci: @83
    flags: { }
    locals: {
'org/springframework/samples/petclinic/owner/Owner_Accessor_yw4ckn',
'org/springframework/data/mapping/PersistentProperty' }
    stack: { 'java/lang/invoke/MethodHandle' }
  Bytecode:
    0000000: 2b12 7db8 0027 2ab4 0029 4d2b b900 8301
    0000010: 00b6 0089 ab00 0000 0000 006c 0000 0006
    0000020: a900 4641 0000 004c bb97 9bf4 0000 0054
    0000030: 0000 0d1b 0000 003c 002e 996b 0000 005c
    0000040: 07ea e95b 0000 0044 2eae b404 0000 0064
    0000050: b200 4a2c b600 a5b0 b200 532c b600 a5b0
    0000060: b200 592c b600 a5b0 b200 5f2c b600 a5b0
    0000070: b200 652c b600 a5b0 b200 6b2c b600 a5b0
    0000080: bb00 9159 12a7 04bd 0004 5903 2b53 b800
    0000090: 97b7 009a bf
  Stackmap Table:
    same_frame_extended(@80)
    same_frame(@88)
    same_frame(@96)
    same_frame(@104)
    same_frame(@112)
    same_frame(@120)
    same_frame(@128)

I have shared the related output I get with -Xlog:exceptions on
https://gist.github.com/sdeleuze/96e638dd3bb94918c545ee54fca9b8a3 in case
that could be useful.


On Wed, Sep 11, 2024 at 2:51?PM Alan Bateman <alan.bateman at oracle.com>
wrote:

> On 11/09/2024 13:16, Sebastien Deleuze wrote:
> > Yes, it works without --add-opens and without -XX:CacheDataStore, in
> > all my use cases I never set --add-opens explicitly.
> >
> > There are various fallback paths, and potentially the original
> > exception is hidden, so let me have a deeper look by comparing broken
> > and successful code paths.
> > I will share more details in an upcoming email.
> >
> Maybe running with -Xlog:exceptions might reveal something.
>
> -Alan
>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240911/a278c78e/attachment.htm>

From adinn at openjdk.org  Wed Sep 11 14:07:55 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 11 Sep 2024 14:07:55 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
Message-ID: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>

This PR modifies AOT compiled method code to load compressed oops base and shift constants via the AOTRuntimeConstants area rather than encode them as immediates. It also unlatches the currently forced setting of UseCompatibleCompressedOops, allowing the heap to be allocated wherever it will fit.

-------------

Commit messages:
 - Store and load CompressedOops base/shift via AOTRuntimeConstants on aarch64
 - Use AOTRuntimeConstants to store and load CompressedOops base and shift

Changes: https://git.openjdk.org/leyden/pull/20/files
  Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=20&range=00
  Stats: 269 lines in 9 files changed: 245 ins; 0 del; 24 mod
  Patch: https://git.openjdk.org/leyden/pull/20.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/20/head:pull/20

PR: https://git.openjdk.org/leyden/pull/20

From asmehra at redhat.com  Wed Sep 11 14:14:03 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Wed, 11 Sep 2024 10:14:03 -0400
Subject: premain: Crash in Infinispan server code caused by NPE under
 MethodHandleNative::linkDynamicConstant
In-Reply-To: <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>
References: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
 <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>
Message-ID: <CAKt0pySztvwsadtrqjai6XwakAWq_v_o8men4aopLo4X-0azyQ@mail.gmail.com>

Hi Andrew,
Thanks for sharing the initial investigation.
I have been looking into this and have a few of things to add to your
analysis:

1.  As you mentioned the classData for the lambda
class WildFlyElytronBaseProvider$$Lambda is null.
The classData is stored in the mirror object of the InstanceKlass when the
class is defined through JVM_LookupDefineClass.
However, when we create the scratch mirror object (which get stored in the
AOT cache) the classData is not populated.
See
https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp#L1128-L1131

  Handle classData; // set to null. Will be reinitialized at runtime
  Handle mirror;
  Handle comp_mirror;
  allocate_mirror(k, /*is_scratch=*/true, protection_domain, classData,
mirror, comp_mirror, CHECK);

So this explains why the call to classData(caller.lookupClass()) returned
null.

2. In the mainline there is a check in InnerClassLambdaMetafactory.java for
the particular code pattern used by the application.
If this code pattern is found then the lambda proxy class is not included
in the CDS archive.
See
https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L163-L170
and
https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L246

        // If the target class invokes a protected method inherited from a
        // superclass in a different package, or does 'invokespecial', the
        // lambda class has no access to the resolved method, or does
        // 'invokestatic' on a hidden class which cannot be resolved by
name.
        // Instead, we need to pass the live implementation method handle to
        // the proxy class to invoke directly. (javac prefers to avoid this
        // situation by generating bridges in the target class)
        useImplMethodHandle =
(Modifier.isProtected(implInfo.getModifiers()) &&
                               !VerifyAccess.isSamePackage(targetClass,
implInfo.getDeclaringClass())) ||
                               implKind ==
MethodHandleInfo.REF_invokeSpecial ||
                               implKind ==
MethodHandleInfo.REF_invokeStatic && implClass.isHidden();

In premain lambda proxy classes get included in the AOT cache as a result
of indy resolution and that mechanism doesn't have this kind of check.

3. For the null classData problem mentioned above, I tried to fix it by
storing classData in the scratch mirror using the following patch:

diff --git a/src/hotspot/share/classfile/javaClasses.cpp
b/src/hotspot/share/classfile/javaClasses.cpp
index bd8141adbcc..41766e98093 100644
--- a/src/hotspot/share/classfile/javaClasses.cpp
+++ b/src/hotspot/share/classfile/javaClasses.cpp
@@ -1094,9 +1094,9 @@ void java_lang_Class::create_mirror(Klass* k, Handle
class_loader,
     }
     if (CDSConfig::is_dumping_heap()) {
       if (CDSConfig::is_dumping_protection_domains()) {
-        create_scratch_mirror(k, protection_domain, CHECK);
+        create_scratch_mirror(k, protection_domain, classData, CHECK);
       } else {
-        create_scratch_mirror(k, Handle() /* null protection_domain*/,
CHECK);
+        create_scratch_mirror(k, Handle() /* null protection_domain*/,
classData, CHECK);
       }
     }
   } else {
@@ -1117,7 +1117,7 @@ void java_lang_Class::create_mirror(Klass* k, Handle
class_loader,
 // Note: we archive the "scratch mirror" instead of k->java_mirror(),
because the
 // latter may contain dumptime-specific information that cannot be archived
 // (e.g., ClassLoaderData*, or static fields that are modified by Java
code execution).
-void java_lang_Class::create_scratch_mirror(Klass* k, Handle
protection_domain, TRAPS) {
+void java_lang_Class::create_scratch_mirror(Klass* k, Handle
protection_domain, Handle classData, TRAPS) {
   if (k->class_loader() != nullptr &&
       k->class_loader() != SystemDictionary::java_platform_loader() &&
       k->class_loader() != SystemDictionary::java_system_loader()) {
@@ -1125,9 +1125,11 @@ void java_lang_Class::create_scratch_mirror(Klass*
k, Handle protection_domain,
     return;
   }

-  Handle classData; // set to null. Will be reinitialized at runtime
+  //Handle classData; // set to null. Will be reinitialized at runtime
   Handle mirror;
   Handle comp_mirror;
   allocate_mirror(k, /*is_scratch=*/true, protection_domain, classData,
mirror, comp_mirror, CHECK);

   if (comp_mirror() != nullptr) {
diff --git a/src/hotspot/share/classfile/javaClasses.hpp
b/src/hotspot/share/classfile/javaClasses.hpp
index bc49a0861a7..7ec2a2556dd 100644
--- a/src/hotspot/share/classfile/javaClasses.hpp
+++ b/src/hotspot/share/classfile/javaClasses.hpp
@@ -263,7 +263,7 @@ class java_lang_Class : AllStatic {

   // Archiving
   static void serialize_offsets(SerializeClosure* f) NOT_CDS_RETURN;
-  static void create_scratch_mirror(Klass* k, Handle protection_domain,
TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
+  static void create_scratch_mirror(Klass* k, Handle protection_domain,
Handle classData, TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
   static bool restore_archived_mirror(Klass *k, Handle class_loader,
Handle module,
                                       Handle protection_domain,
                                       TRAPS)
NOT_CDS_JAVA_HEAP_RETURN_(false);

But this resulted in a different exception:

Exception in thread "main" java.lang.ExceptionInInitializerError
at com.redhat.leyden.Main.main(Main.java:7)
Caused by: java.lang.invoke.WrongMethodTypeException: handle's method type
(WildFlyElytronBaseProvider,Service)void but found
(WildFlyElytronBaseProvider,Service)void
at
java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
at java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
at
java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
at
org.wildfly.security.WildFlyElytronBaseProvider$$Lambda/0x80000000c.accept(Unknown
Source)
at
org.wildfly.security.WildFlyElytronBaseProvider.putMakedPasswordImplementations(WildFlyElytronBaseProvider.java:112)
at
org.wildfly.security.WildFlyElytronBaseProvider.putPasswordImplementations(WildFlyElytronBaseProvider.java:107)
at
org.wildfly.security.password.WildFlyElytronPasswordProvider.<init>(WildFlyElytronPasswordProvider.java:43)
at
org.wildfly.security.password.WildFlyElytronPasswordProvider.<clinit>(WildFlyElytronPasswordProvider.java:36)
... 1 more

The exception message is strange because the handle's method type and the
expected type are both symbolically the same.
I am debugging this exception at the moment.

Thanks,
- Ashutosh Mehra


On Wed, Sep 11, 2024 at 6:03?AM Andrew Dinn <adinn at redhat.com> wrote:

> Oops, sorry, I debugged this a few days ago! Correction to a few details:
>
> On 11/09/2024 10:39, Andrew Dinn wrote:
> > A crash due to an NPE was observed in the Infinispan (Data Grid) server
> > app when deployed using the Leyden EA. The crash still manifests with
> > the latest premain code. The crash happens below an application call
> > which employs a method reference as argument
> >
> >          putMakedPasswordImplementations(this::putService, this);
>
> The called method in turn calls consumer.accept
>
>              consumer.accept(new Service(provider,
> PASSWORD_FACTORY_TYPE, algorithm,
> "org.wildfly.security.password.impl.PasswordFactorySpiImpl", emptyList,
> emptyMap));
>
> which enters enters MethodHandleNative::linkDynamicConstant()
>
> > Debugging shows that the call to linkDynamicConstant() returns null.
> >
> > A simple reproducer for the problem is available as a maven project on
> > github:
> >
> >    https://github.com/tristantarrant/elytron-leyden
> >
> > The ReadMe provides an explanation of how to reproduce the problem. I
> > did so and the debugged to find out some of the details of what is
> > happening (see below) but did not fully clarify the problem. Help from
> > someone more conversant with the ins and outs of method handle
> > bootstraps in premain would be welcome. Details follow.
> >
> > regards,
> >
> >
> > Andrew Dinn
> > -----------
> >
> > I downloaded the git repo and attached the Java sources using Maven
> command
> >
> >    $ mvn dependency:sources
> >
> > Having manifested the crash by following the instructions in the README
> > I reran the leyden JVM under gdb using the following commands to enable
> > Java debugging
> >
> > $ gdb ${LEYDEN_HOME}/bin/java
> > (gdb) cd /path/to/mvn/project
> > (gdb) run
> > -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
> > -classpath
> >
> /home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/
> 2.5.1.Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar
> -XX:CacheDataStore=elytron.aot com.redhat.leyden.Main
> >
> > The problem manifests at WildflyElytronBaseProvider.java:112 in method
> > WildflyElytronBaseProvider::putMakedPasswordImplementations
>
>      static void putMakedPasswordImplementations(Consumer<Service>
> consumer, Provider provider) {
>          for (String algorithm : MASKED_ALGORITHMS) {
>              consumer.accept(new Service(provider,
> PASSWORD_FACTORY_TYPE, algorithm,
> "org.wildfly.security.password.impl.PasswordFactorySpiImpl", emptyList,
> emptyMap)); <== NPE under this call
>          }
>
>
> > The source code for this method can be found in the following source jar
> >
> >
> >
> ${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar
> >
> > (where M2_REPO will normally be ~/.m2/repository)
> >
> > Stepping into accept eventually enters
> MethodHandleNative::linkDynamicConstant
> > which in turn enters into ConstantBootstraps.makeConstant(). The caller
> > Class at this point is a lambda class which prints as
> > org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c
> >
> > Several steps further the code enters BootstrapMethodInvoker::invoke
> > (below the app method call but via 3 hidden frames) with bootstrapMethod
> > bound to a DirectMethodHandle. After several more steps this enters
> > DirectMethodHandle$Holder.invokeStatic which in turn calls
> > MethodHandles::classData(Lookup,String,Class).
> >
> > At this point caller is a MethodHandleLookup for the lambda class
> > Lambda/0x800000000c mentioned above. The following call
> >
> >           Object classdata = classData(caller.lookupClass());
> >
> > returns null to DirectMethodHandle$Holder.invokeStatic which pops the
> > same result back out to BootstrapMethodInvoker::invoke at line 90
> >
> >                  if (type instanceof Class<?> c) {
> >                      result = bootstrapMethod.invoke(caller, name, c);
> > <== null
> >
> > This null result pops back out as the value for the call to
> > BootstrapMethodInvoker.invoke(), ConstantBootstraps.makeConstant() and
> > MethodHandleNative::linkDynamicConstant().
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240911/7b8e339a/attachment.htm>

From adinn at openjdk.org  Wed Sep 11 14:20:23 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 11 Sep 2024 14:20:23 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
In-Reply-To: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
Message-ID: <-T1nsTVMKJoru1m_lpX5u5ViTZIQeNCAQUVaFrQE08o=.15785868-3bfc-48e6-993f-cf66ade078b1@github.com>

On Wed, 11 Sep 2024 14:01:59 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> This PR modifies AOT compiled method code to load compressed oops base and shift constants via the AOTRuntimeConstants area rather than encode them as immediates. It also unlatches the currently forced setting of UseCompatibleCompressedOops, allowing the heap to be allocated wherever it will fit.

This has been shown to cater for different encodings by successfully running a javac compile of HelloWorld in two relevant scenarios:

1) Pass -XX:+UseCompatibleCompressedOops to the assembly run; omit it from the production run 
2) default heap size on assembly run; pass -Xmx12M to production run

In case 1
  for the assembly run the heap starts at 0x80800000, coops base is 0x80000000 and coops shift is 3
  for the production run the heap is at 0x414000000 coops base is 0x0 and coops shift is 3
In case 2
  for the assembly run the heap is at 0x414000000 coops base is 0x0 and coops shift is 3
  for the production run the heap is at 0xff000000, coops base is 0x0 and shift is 0

-------------

PR Comment: https://git.openjdk.org/leyden/pull/20#issuecomment-2343808594

From adinn at openjdk.org  Wed Sep 11 14:45:58 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 11 Sep 2024 14:45:58 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v2]
In-Reply-To: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
Message-ID: <shiGolUnmKfaNTi1qlO-P0TD7pASS1QgVyMLU5AZxpg=.189f8b78-ac35-40fb-ac9d-31714e050581@github.com>

> This PR modifies AOT compiled method code to load compressed oops base and shift constants via the AOTRuntimeConstants area rather than encode them as immediates. It also unlatches the currently forced setting of UseCompatibleCompressedOops, allowing the heap to be allocated wherever it will fit.

Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:

  only check UseCompatibleCompressedOops on 64 bit builds

-------------

Changes:
  - all: https://git.openjdk.org/leyden/pull/20/files
  - new: https://git.openjdk.org/leyden/pull/20/files/e59b1e82..ce901a9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=leyden&pr=20&range=01
 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=20&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/leyden/pull/20.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/20/head:pull/20

PR: https://git.openjdk.org/leyden/pull/20

From asmehra at redhat.com  Wed Sep 11 19:12:00 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Wed, 11 Sep 2024 15:12:00 -0400
Subject: premain: Crash in Infinispan server code caused by NPE under
 MethodHandleNative::linkDynamicConstant
In-Reply-To: <CAKt0pySztvwsadtrqjai6XwakAWq_v_o8men4aopLo4X-0azyQ@mail.gmail.com>
References: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
 <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>
 <CAKt0pySztvwsadtrqjai6XwakAWq_v_o8men4aopLo4X-0azyQ@mail.gmail.com>
Message-ID: <CAKt0pyQ44E+npyUW35Zhxg+PfBgF2yuNgS61gj1GGj=aLGTJXw@mail.gmail.com>

Regarding the WrongMethodTypeException that I mentioned in my previous
email (see pt 3),
this exception happens when lambda proxy class attempts to invoke the
MethodHandle it obtained from the classData:

  public void accept(java.lang.Object);
    descriptor: (Ljava/lang/Object;)V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=3, locals=2, args_size=2
         0: ldc           #26                 // Dynamic
#0:_:Ljava/lang/invoke/MethodHandle;
         2: aload_0
         3: getfield      #13                 // Field
arg$1:Lorg/wildfly/security/WildFlyElytronBaseProvider;
         6: aload_1
         7: checkcast     #28                 // class
java/security/Provider$Service
        10: invokevirtual #34                 // Method
java/lang/invoke/MethodHandle.invokeExact:(Lorg/wildfly/security/WildFlyElytronBaseProvider;Ljava/security/Provider$Service;)V
        13: return

The scenario is during the assembly phase as part of the indy resolution
the MethodHandle for which the exception is thrown gets created.
Normally MethodHandle's type gets added in MethodType::internTable but by
the time indy resolution happens, JVM has already taken
snapshot of the MethodType::internTable through an upcall to
MethodType::createArchivedObjects().
As a result the AOTCache ends up with the MethodType object which is not in
AOTHolder.archivedMethodTypes.

During the production run, when the jvm invokes the MethodHandle, it
searches for the MethodType corresponding to the signature passed at the
callsite.
As expected, it fails to find it in the AOTHolder.archivedMethodTypes, so
it creates a new instance of the MethodType.
But Invokers.checkExactType() relies on the MethodHandle's type to be the
same object as the MethodType object passed as parameter.

    static void checkExactType(MethodHandle mhM, MethodType expected) {
        MethodType targetType = mh.type();
        if (targetType != expected)
            throw newWrongMethodTypeException(targetType, expected);
    }

Hence, it throws WrongMethodTypeException though the two MT objects have
the same signature.

To handle this scenario, I changed the order of indy resolution and upcall
to MethodType::createArchivedObjects() as:

diff --git a/src/hotspot/share/cds/metaspaceShared.cpp
b/src/hotspot/share/cds/metaspaceShared.cpp
index df4bcadefa3..457716cac5b 100644
--- a/src/hotspot/share/cds/metaspaceShared.cpp
+++ b/src/hotspot/share/cds/metaspaceShared.cpp
@@ -751,6 +751,20 @@ void MetaspaceShared::link_shared_classes(bool
jcmd_request, TRAPS) {
   if (CDSConfig::is_dumping_final_static_archive()) {
     FinalImageRecipes::apply_recipes(CHECK);
   }
+
+#if INCLUDE_CDS_JAVA_HEAP
+  if (CDSConfig::is_dumping_invokedynamic()) {
+    // This makes sure that the MethodType and MethodTypeForm tables won't
be updated
+    // concurrently when we are saving their contents into a side table.
+    assert(CDSConfig::allow_only_single_java_thread(), "Required");
+
+    JavaValue result(T_VOID);
+    JavaCalls::call_static(&result, vmClasses::MethodType_klass(),
+                           vmSymbols::createArchivedObjects(),
+                           vmSymbols::void_method_signature(),
+                           CHECK);
+  }
+#endif
 }

Note that indy resolution happens as part of
FinalImageRecipes::apply_recipes(CHECK)
which is now invoked before the upcall to createArchivedObjects().
With this change I am able to run the application without any exceptions.
My complete patch can be seen here:
https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
I will do more testing with this patch.

@Ioi Lam <ioi.lam at oracle.com> do you have any feedback on this patch.

Thanks,
- Ashutosh Mehra



On Wed, Sep 11, 2024 at 10:14?AM Ashutosh Mehra <asmehra at redhat.com> wrote:

> Hi Andrew,
> Thanks for sharing the initial investigation.
> I have been looking into this and have a few of things to add to your
> analysis:
>
> 1.  As you mentioned the classData for the lambda
> class WildFlyElytronBaseProvider$$Lambda is null.
> The classData is stored in the mirror object of the InstanceKlass when the
> class is defined through JVM_LookupDefineClass.
> However, when we create the scratch mirror object (which get stored in the
> AOT cache) the classData is not populated.
> See
> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp#L1128-L1131
>
>   Handle classData; // set to null. Will be reinitialized at runtime
>   Handle mirror;
>   Handle comp_mirror;
>   allocate_mirror(k, /*is_scratch=*/true, protection_domain, classData,
> mirror, comp_mirror, CHECK);
>
> So this explains why the call to classData(caller.lookupClass()) returned
> null.
>
> 2. In the mainline there is a check in InnerClassLambdaMetafactory.java
> for the particular code pattern used by the application.
> If this code pattern is found then the lambda proxy class is not included
> in the CDS archive.
> See
> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L163-L170
> and
> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L246
>
>         // If the target class invokes a protected method inherited from a
>         // superclass in a different package, or does 'invokespecial', the
>         // lambda class has no access to the resolved method, or does
>         // 'invokestatic' on a hidden class which cannot be resolved by
> name.
>         // Instead, we need to pass the live implementation method handle
> to
>         // the proxy class to invoke directly. (javac prefers to avoid this
>         // situation by generating bridges in the target class)
>         useImplMethodHandle =
> (Modifier.isProtected(implInfo.getModifiers()) &&
>                                !VerifyAccess.isSamePackage(targetClass,
> implInfo.getDeclaringClass())) ||
>                                implKind ==
> MethodHandleInfo.REF_invokeSpecial ||
>                                implKind ==
> MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>
> In premain lambda proxy classes get included in the AOT cache as a result
> of indy resolution and that mechanism doesn't have this kind of check.
>
> 3. For the null classData problem mentioned above, I tried to fix it by
> storing classData in the scratch mirror using the following patch:
>
> diff --git a/src/hotspot/share/classfile/javaClasses.cpp
> b/src/hotspot/share/classfile/javaClasses.cpp
> index bd8141adbcc..41766e98093 100644
> --- a/src/hotspot/share/classfile/javaClasses.cpp
> +++ b/src/hotspot/share/classfile/javaClasses.cpp
> @@ -1094,9 +1094,9 @@ void java_lang_Class::create_mirror(Klass* k, Handle
> class_loader,
>      }
>      if (CDSConfig::is_dumping_heap()) {
>        if (CDSConfig::is_dumping_protection_domains()) {
> -        create_scratch_mirror(k, protection_domain, CHECK);
> +        create_scratch_mirror(k, protection_domain, classData, CHECK);
>        } else {
> -        create_scratch_mirror(k, Handle() /* null protection_domain*/,
> CHECK);
> +        create_scratch_mirror(k, Handle() /* null protection_domain*/,
> classData, CHECK);
>        }
>      }
>    } else {
> @@ -1117,7 +1117,7 @@ void java_lang_Class::create_mirror(Klass* k, Handle
> class_loader,
>  // Note: we archive the "scratch mirror" instead of k->java_mirror(),
> because the
>  // latter may contain dumptime-specific information that cannot be
> archived
>  // (e.g., ClassLoaderData*, or static fields that are modified by Java
> code execution).
> -void java_lang_Class::create_scratch_mirror(Klass* k, Handle
> protection_domain, TRAPS) {
> +void java_lang_Class::create_scratch_mirror(Klass* k, Handle
> protection_domain, Handle classData, TRAPS) {
>    if (k->class_loader() != nullptr &&
>        k->class_loader() != SystemDictionary::java_platform_loader() &&
>        k->class_loader() != SystemDictionary::java_system_loader()) {
> @@ -1125,9 +1125,11 @@ void java_lang_Class::create_scratch_mirror(Klass*
> k, Handle protection_domain,
>      return;
>    }
>
> -  Handle classData; // set to null. Will be reinitialized at runtime
> +  //Handle classData; // set to null. Will be reinitialized at runtime
>    Handle mirror;
>    Handle comp_mirror;
>    allocate_mirror(k, /*is_scratch=*/true, protection_domain, classData,
> mirror, comp_mirror, CHECK);
>
>    if (comp_mirror() != nullptr) {
> diff --git a/src/hotspot/share/classfile/javaClasses.hpp
> b/src/hotspot/share/classfile/javaClasses.hpp
> index bc49a0861a7..7ec2a2556dd 100644
> --- a/src/hotspot/share/classfile/javaClasses.hpp
> +++ b/src/hotspot/share/classfile/javaClasses.hpp
> @@ -263,7 +263,7 @@ class java_lang_Class : AllStatic {
>
>    // Archiving
>    static void serialize_offsets(SerializeClosure* f) NOT_CDS_RETURN;
> -  static void create_scratch_mirror(Klass* k, Handle protection_domain,
> TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
> +  static void create_scratch_mirror(Klass* k, Handle protection_domain,
> Handle classData, TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>    static bool restore_archived_mirror(Klass *k, Handle class_loader,
> Handle module,
>                                        Handle protection_domain,
>                                        TRAPS)
> NOT_CDS_JAVA_HEAP_RETURN_(false);
>
> But this resulted in a different exception:
>
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at com.redhat.leyden.Main.main(Main.java:7)
> Caused by: java.lang.invoke.WrongMethodTypeException: handle's method type
> (WildFlyElytronBaseProvider,Service)void but found
> (WildFlyElytronBaseProvider,Service)void
> at
> java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
> at java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
> at
> java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
> at
> org.wildfly.security.WildFlyElytronBaseProvider$$Lambda/0x80000000c.accept(Unknown
> Source)
> at
> org.wildfly.security.WildFlyElytronBaseProvider.putMakedPasswordImplementations(WildFlyElytronBaseProvider.java:112)
> at
> org.wildfly.security.WildFlyElytronBaseProvider.putPasswordImplementations(WildFlyElytronBaseProvider.java:107)
> at
> org.wildfly.security.password.WildFlyElytronPasswordProvider.<init>(WildFlyElytronPasswordProvider.java:43)
> at
> org.wildfly.security.password.WildFlyElytronPasswordProvider.<clinit>(WildFlyElytronPasswordProvider.java:36)
> ... 1 more
>
> The exception message is strange because the handle's method type and the
> expected type are both symbolically the same.
> I am debugging this exception at the moment.
>
> Thanks,
> - Ashutosh Mehra
>
>
> On Wed, Sep 11, 2024 at 6:03?AM Andrew Dinn <adinn at redhat.com> wrote:
>
>> Oops, sorry, I debugged this a few days ago! Correction to a few details:
>>
>> On 11/09/2024 10:39, Andrew Dinn wrote:
>> > A crash due to an NPE was observed in the Infinispan (Data Grid) server
>> > app when deployed using the Leyden EA. The crash still manifests with
>> > the latest premain code. The crash happens below an application call
>> > which employs a method reference as argument
>> >
>> >          putMakedPasswordImplementations(this::putService, this);
>>
>> The called method in turn calls consumer.accept
>>
>>              consumer.accept(new Service(provider,
>> PASSWORD_FACTORY_TYPE, algorithm,
>> "org.wildfly.security.password.impl.PasswordFactorySpiImpl", emptyList,
>> emptyMap));
>>
>> which enters enters MethodHandleNative::linkDynamicConstant()
>>
>> > Debugging shows that the call to linkDynamicConstant() returns null.
>> >
>> > A simple reproducer for the problem is available as a maven project on
>> > github:
>> >
>> >    https://github.com/tristantarrant/elytron-leyden
>> >
>> > The ReadMe provides an explanation of how to reproduce the problem. I
>> > did so and the debugged to find out some of the details of what is
>> > happening (see below) but did not fully clarify the problem. Help from
>> > someone more conversant with the ins and outs of method handle
>> > bootstraps in premain would be welcome. Details follow.
>> >
>> > regards,
>> >
>> >
>> > Andrew Dinn
>> > -----------
>> >
>> > I downloaded the git repo and attached the Java sources using Maven
>> command
>> >
>> >    $ mvn dependency:sources
>> >
>> > Having manifested the crash by following the instructions in the README
>> > I reran the leyden JVM under gdb using the following commands to enable
>> > Java debugging
>> >
>> > $ gdb ${LEYDEN_HOME}/bin/java
>> > (gdb) cd /path/to/mvn/project
>> > (gdb) run
>> > -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
>> > -classpath
>> >
>> /home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/
>> 2.5.1.Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar
>> -XX:CacheDataStore=elytron.aot com.redhat.leyden.Main
>> >
>> > The problem manifests at WildflyElytronBaseProvider.java:112 in method
>> > WildflyElytronBaseProvider::putMakedPasswordImplementations
>>
>>      static void putMakedPasswordImplementations(Consumer<Service>
>> consumer, Provider provider) {
>>          for (String algorithm : MASKED_ALGORITHMS) {
>>              consumer.accept(new Service(provider,
>> PASSWORD_FACTORY_TYPE, algorithm,
>> "org.wildfly.security.password.impl.PasswordFactorySpiImpl", emptyList,
>> emptyMap)); <== NPE under this call
>>          }
>>
>>
>> > The source code for this method can be found in the following source jar
>> >
>> >
>> >
>> ${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar
>> >
>> > (where M2_REPO will normally be ~/.m2/repository)
>> >
>> > Stepping into accept eventually enters
>> MethodHandleNative::linkDynamicConstant
>> > which in turn enters into ConstantBootstraps.makeConstant(). The caller
>> > Class at this point is a lambda class which prints as
>> > org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c
>> >
>> > Several steps further the code enters BootstrapMethodInvoker::invoke
>> > (below the app method call but via 3 hidden frames) with
>> bootstrapMethod
>> > bound to a DirectMethodHandle. After several more steps this enters
>> > DirectMethodHandle$Holder.invokeStatic which in turn calls
>> > MethodHandles::classData(Lookup,String,Class).
>> >
>> > At this point caller is a MethodHandleLookup for the lambda class
>> > Lambda/0x800000000c mentioned above. The following call
>> >
>> >           Object classdata = classData(caller.lookupClass());
>> >
>> > returns null to DirectMethodHandle$Holder.invokeStatic which pops the
>> > same result back out to BootstrapMethodInvoker::invoke at line 90
>> >
>> >                  if (type instanceof Class<?> c) {
>> >                      result = bootstrapMethod.invoke(caller, name, c);
>> > <== null
>> >
>> > This null result pops back out as the value for the call to
>> > BootstrapMethodInvoker.invoke(), ConstantBootstraps.makeConstant() and
>> > MethodHandleNative::linkDynamicConstant().
>> >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240911/d24798e8/attachment.htm>

From macarte at openjdk.org  Wed Sep 11 21:44:29 2024
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 11 Sep 2024 21:44:29 GMT
Subject: RFR: 8335358 - alternative ways to trigger the end of training run
Message-ID: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>

AOT training can be ended using either

- -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
- -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
- jcmd AOT.end_training

supports arm64 and x64

note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)

JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358

-------------

Commit messages:
 - whitespace fixes
 - For c1 and c2 we add the trigger test at code gen, interpreter cant do this as method_entry are shared.
 - Consistant naming and remove debug code
 - the core trigger method should not be counted, but the compiled code call it indirectly predicated by the counter.  This is so that jcmd works and is NOT predicated on any counter value
 - Added optional count parameter
 - ignore AOTCreateOnMethodEntry when CDSPreimage is specified
 - fixed patch merge issue
 - added support for x86
 - fixed c1 and c2 issues
 - fixed patch issues
 - ... and 6 more: https://git.openjdk.org/leyden/compare/cf036d70...ad3d6f18

Changes: https://git.openjdk.org/leyden/pull/21/files
  Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335358
  Stats: 277 lines in 28 files changed: 260 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/leyden/pull/21.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/21/head:pull/21

PR: https://git.openjdk.org/leyden/pull/21

From macarte at openjdk.org  Wed Sep 11 21:59:49 2024
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 11 Sep 2024 21:59:49 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v2]
In-Reply-To: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
Message-ID: <O_f9J5s2S0RYJq_ClRttKE2OTSFvyyFXxNZekOlal0Y=.ee10350f-6fa7-4bb1-a92c-fb61b1d33df7@github.com>

> AOT training can be ended using either
> 
> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
> - jcmd <pid> AOT.end_training
> 
> supports arm64 and x64
> 
> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
> 
> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  missing include that was not a problem on osx

-------------

Changes:
  - all: https://git.openjdk.org/leyden/pull/21/files
  - new: https://git.openjdk.org/leyden/pull/21/files/ad3d6f18..21d5afb3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=01
 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/leyden/pull/21.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/21/head:pull/21

PR: https://git.openjdk.org/leyden/pull/21

From macarte at openjdk.org  Wed Sep 11 22:24:53 2024
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 11 Sep 2024 22:24:53 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v3]
In-Reply-To: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
Message-ID: <sGbZxClkC1gVEtSjILXVTarW-ns_8Vv3Ylgbgq7rLqY=.29b21ee8-da43-44d8-b882-e194f4a79cb3@github.com>

> AOT training can be ended using either
> 
> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
> - jcmd <pid> AOT.end_training
> 
> supports arm64 and x64
> 
> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
> 
> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  another missing include that impacts some build configurations

-------------

Changes:
  - all: https://git.openjdk.org/leyden/pull/21/files
  - new: https://git.openjdk.org/leyden/pull/21/files/21d5afb3..b3098cfc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=02
 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/leyden/pull/21.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/21/head:pull/21

PR: https://git.openjdk.org/leyden/pull/21

From ioi.lam at oracle.com  Thu Sep 12 03:07:34 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Wed, 11 Sep 2024 20:07:34 -0700
Subject: premain: CGLIB error during the training run with Petclinic
In-Reply-To: <CAG5jep8kCfuFELbN3T=aZds3=UvMCWL64LrD=yPd58KYJXHaPA@mail.gmail.com>
References: <CAG5jep_f8Ne8wRBEfD9hHB7TzLB-Axip6Yrnc6rz0SobgALOZw@mail.gmail.com>
 <a8fd083c-4731-446e-9117-9898e8fe9fef@oracle.com>
 <CAG5jep--vGCe--6FeOTiG_m4Ye+3JtHYBTfQA5mygDjPMYQsdg@mail.gmail.com>
 <4c7c879e-1488-41a8-a8e0-97d9f1379687@oracle.com>
 <CAG5jep8kCfuFELbN3T=aZds3=UvMCWL64LrD=yPd58KYJXHaPA@mail.gmail.com>
Message-ID: <93e83e4d-b75a-4c75-8935-08e4697cade7@oracle.com>

It seems like the error happens only when running in "training mode". 
Can you try something like this to isolate the problem?

 ??? rm -f app.cds
 ??? java -cp app.jar -XX:CacheDataStore -XX:+UnlockDiagnosticVMOptions 
-XX:+CDSManualFinalImage AppMain

This will make sure that the app is executed with profile collection 
enabled. The profile is written to the file foo.cds.preimage.

Normally, after foo.cds.preimage is created, we fork a sub process to 
consume foo.cds.preimage and write foo.cds. -XX:+CDSManualFinalImage 
prevents the sub process from being created.

If the above causes an error, but this doesn't (when running the exact 
same workload)

 ??? java -cp app.jar -Xshare:off AppMain

then we know that the error is triggered by the extra work performed by 
the VM for collecting profiling information.

Thanks

- Ioi

On 9/11/24 6:02 AM, Sebastien Deleuze wrote:
> After adding more logging, I can confirm the original exception when 
> -XX:CacheDataStore is set with no existing CDS file is thrown by 
> MethodHandles.Lookup#defineClass and is similar to the second one I 
> reported.
> This is a class that Spring Data generates during runtime.
>
> java.lang.VerifyError: Bad local variable type
> Exception Details:
> ? Location:
> org/springframework/samples/petclinic/owner/Owner_Accessor_yw4ckn.getProperty(Lorg/springframework/data/mapping/PersistentProperty;)Ljava/lang/Object; 
> @83: aload_2
> ? Reason:
> ? ? Type top (current frame, locals[2]) is not assignable to reference 
> type
> ? Current Frame:
> ? ? bci: @83
> ? ? flags: { }
> ? ? locals: { 
> 'org/springframework/samples/petclinic/owner/Owner_Accessor_yw4ckn', 
> 'org/springframework/data/mapping/PersistentProperty' }
> ? ? stack: { 'java/lang/invoke/MethodHandle' }
> ? Bytecode:
> ? ? 0000000: 2b12 7db8 0027 2ab4 0029 4d2b b900 8301
> ? ? 0000010: 00b6 0089 ab00 0000 0000 006c 0000 0006
> ? ? 0000020: a900 4641 0000 004c bb97 9bf4 0000 0054
> ? ? 0000030: 0000 0d1b 0000 003c 002e 996b 0000 005c
> ? ? 0000040: 07ea e95b 0000 0044 2eae b404 0000 0064
> ? ? 0000050: b200 4a2c b600 a5b0 b200 532c b600 a5b0
> ? ? 0000060: b200 592c b600 a5b0 b200 5f2c b600 a5b0
> ? ? 0000070: b200 652c b600 a5b0 b200 6b2c b600 a5b0
> ? ? 0000080: bb00 9159 12a7 04bd 0004 5903 2b53 b800
> ? ? 0000090: 97b7 009a bf
> ? Stackmap Table:
> ? ? same_frame_extended(@80)
> ? ? same_frame(@88)
> ? ? same_frame(@96)
> ? ? same_frame(@104)
> ? ? same_frame(@112)
> ? ? same_frame(@120)
> ? ? same_frame(@128)
>
> I have shared the related output I get with -Xlog:exceptions on 
> https://gist.github.com/sdeleuze/96e638dd3bb94918c545ee54fca9b8a3 in 
> case that could be useful.
>
>
> On Wed, Sep 11, 2024 at 2:51?PM Alan Bateman <alan.bateman at oracle.com> 
> wrote:
>
>     On 11/09/2024 13:16, Sebastien Deleuze wrote:
>     > Yes, it works?without --add-opens and without
>     -XX:CacheDataStore, in
>     > all my use cases I never set --add-opens explicitly.
>     >
>     > There are various fallback?paths, and potentially the original
>     > exception is hidden, so let me have a deeper look by comparing
>     broken
>     > and successful code paths.
>     > I will share more details in an upcoming email.
>     >
>     Maybe running with -Xlog:exceptions might reveal something.
>
>     -Alan
>
>
> This electronic communication and the information and any files 
> transmitted with it, or attached to it, are confidential and are 
> intended solely for the use of the individual or entity to whom it is 
> addressed and may contain information that is confidential, legally 
> privileged, protected by privacy laws, or otherwise restricted from 
> disclosure to anyone else. If you are not the intended recipient or 
> the person responsible for delivering the e-mail to the intended 
> recipient, you are hereby notified that any use, copying, 
> distributing, dissemination, forwarding, printing, or copying of this 
> e-mail is strictly prohibited. If you received this e-mail in error, 
> please return the e-mail to the sender, delete it from your computer, 
> and destroy any printed copy of it. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240911/2a910d55/attachment.htm>

From ioi.lam at oracle.com  Thu Sep 12 03:25:19 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Wed, 11 Sep 2024 20:25:19 -0700
Subject: [External] : Re: premain: Crash in Infinispan server code caused
 by NPE under MethodHandleNative::linkDynamicConstant
In-Reply-To: <CAKt0pyQ44E+npyUW35Zhxg+PfBgF2yuNgS61gj1GGj=aLGTJXw@mail.gmail.com>
References: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
 <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>
 <CAKt0pySztvwsadtrqjai6XwakAWq_v_o8men4aopLo4X-0azyQ@mail.gmail.com>
 <CAKt0pyQ44E+npyUW35Zhxg+PfBgF2yuNgS61gj1GGj=aLGTJXw@mail.gmail.com>
Message-ID: <80566c33-0970-4521-8677-3d01bd98fe09@oracle.com>

On 9/11/24 12:12 PM, Ashutosh Mehra wrote:

> Regarding the WrongMethodTypeException that I mentioned in my previous 
> email (see pt 3),
> this exception happens when lambda proxy class attempts to invoke the 
> MethodHandle it obtained from the classData:
>
> ? public void accept(java.lang.Object);
> ? ? descriptor: (Ljava/lang/Object;)V
> ? ? flags: (0x0001) ACC_PUBLIC
> ? ? Code:
> ? ? ? stack=3, locals=2, args_size=2
> ? ? ? ? ?0: ldc ? ? ? ? ? #26 ? ? ? ? ? ? ? ? // Dynamic 
> #0:_:Ljava/lang/invoke/MethodHandle;
> ? ? ? ? ?2: aload_0
> ? ? ? ? ?3: getfield ? ? ?#13 ? ? ? ? ? ? ? ? // Field 
> arg$1:Lorg/wildfly/security/WildFlyElytronBaseProvider;
> ? ? ? ? ?6: aload_1
> ? ? ? ? ?7: checkcast ? ? #28 ? ? ? ? ? ? ? ? // class 
> java/security/Provider$Service
> ? ? ? ? 10: invokevirtual #34 ? ? ? ? ? ? ? ? // Method 
> java/lang/invoke/MethodHandle.invokeExact:(Lorg/wildfly/security/WildFlyElytronBaseProvider;Ljava/security/Provider$Service;)V
> ? ? ? ? 13: return
>
> The scenario is during the assembly phase as part of the indy 
> resolution the MethodHandle for which the exception is thrown gets 
> created.
> Normally MethodHandle's type gets added in MethodType::internTable but 
> by the time indy resolution happens, JVM has already taken
> snapshot of the MethodType::internTable through an upcall to 
> MethodType::createArchivedObjects().
> As a result the AOTCache ends up with the MethodType object which is 
> not in AOTHolder.archivedMethodTypes.
>
> During the production run, when the jvm invokes the MethodHandle, it 
> searches for the MethodType corresponding to the signature passed at 
> the callsite.
> As expected, it fails to find it in the AOTHolder.archivedMethodTypes, 
> so it creates a new instance of the MethodType.
> But Invokers.checkExactType() relies on the MethodHandle's?type to be 
> the same object as the MethodType object passed as parameter.
>
> ? ? static void checkExactType(MethodHandle mhM, MethodType expected) {
> ? ? ? ? MethodType targetType = mh.type();
> ? ? ? ? if (targetType != expected)
> ? ? ? ? ? ? throw newWrongMethodTypeException(targetType, expected);
> ? ? }
>
> Hence, it throws WrongMethodTypeException?though the two MT objects 
> have the same signature.
>
> To handle this scenario, I changed the order of indy resolution and 
> upcall to MethodType::createArchivedObjects()?as:
>
> diff --git a/src/hotspot/share/cds/metaspaceShared.cpp 
> b/src/hotspot/share/cds/metaspaceShared.cpp
> index df4bcadefa3..457716cac5b 100644
> --- a/src/hotspot/share/cds/metaspaceShared.cpp
> +++ b/src/hotspot/share/cds/metaspaceShared.cpp
> @@ -751,6 +751,20 @@ void MetaspaceShared::link_shared_classes(bool 
> jcmd_request, TRAPS) {
> ? ?if (CDSConfig::is_dumping_final_static_archive()) {
> ? ? ?FinalImageRecipes::apply_recipes(CHECK);
> ? ?}
> +
> +#if INCLUDE_CDS_JAVA_HEAP
> + ?if (CDSConfig::is_dumping_invokedynamic()) {
> + ? ?// This makes sure that the MethodType and MethodTypeForm tables 
> won't be updated
> + ? ?// concurrently when we are saving their contents into a side table.
> + ? ?assert(CDSConfig::allow_only_single_java_thread(), "Required");
> +
> + ? ?JavaValue result(T_VOID);
> + ? ?JavaCalls::call_static(&result, vmClasses::MethodType_klass(),
> + vmSymbols::createArchivedObjects(),
> + vmSymbols::void_method_signature(),
> + ? ? ? ? ? ? ? ? ? ? ? ? ? CHECK);
> + ?}
> +#endif
> ?}
> Note that indy resolution happens as part of 
> FinalImageRecipes::apply_recipes(CHECK) which is now invoked before 
> the upcall to createArchivedObjects().
> With this change I am able to run the application without any exceptions.
> My complete patch can be seen here: 
> https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e 
> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!M5PIaQwz6ZHuzVVtZJNYTX90hyGcXPERPk54_t8SkHB7Yx1MU18tVDgW5SHylTR4SuJU8OYzOogcLA$>
> I will do more testing with this patch.
>
> @Ioi Lam <mailto:ioi.lam at oracle.com>?do you have any feedback on this 
> patch.
>

Hi Ashutosh,

Thank you so much for the analysis. Your fix looks correct.

Actually I am quite surprised that the current code works at all, as we 
are not saving most of the MethodTypes created inside 
FinalImageRecipes::apply_recipes(). It must have been a miracle :-)

Could you add a printf into createArchivedObjects to see how many 
MethodTypes are archived, before/after your fix?

Thanks

- Ioi


> Thanks,
> - Ashutosh Mehra
>
>
>
> On Wed, Sep 11, 2024 at 10:14?AM Ashutosh Mehra <asmehra at redhat.com> 
> wrote:
>
>     Hi Andrew,
>     Thanks for sharing the initial investigation.
>     I have been looking into this and have a few of things to add to
>     your analysis:
>
>     1.? As you mentioned the classData for the lambda
>     class?WildFlyElytronBaseProvider$$Lambda is null.
>     The classData is stored in the mirror object of the InstanceKlass
>     when the class is defined through?JVM_LookupDefineClass.
>     However, when we create the scratch mirror object (which get
>     stored in the AOT cache) the classData is not populated.
>     See
>     https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp#L1128-L1131
>     <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp*L1128-L1131__;Iw!!ACWV5N9M2RV99hQ!M5PIaQwz6ZHuzVVtZJNYTX90hyGcXPERPk54_t8SkHB7Yx1MU18tVDgW5SHylTR4SuJU8OaVy5yi_A$>
>
>     ? Handle classData; // set to null. Will be reinitialized at runtime
>     ? Handle mirror;
>     ? Handle comp_mirror;
>     ? allocate_mirror(k, /*is_scratch=*/true, protection_domain,
>     classData, mirror, comp_mirror, CHECK);
>
>     So this explains why the call to
>     classData(caller.lookupClass())returned null.
>
>     2. In the mainline there is a check
>     in?InnerClassLambdaMetafactory.java for the particular code
>     pattern used by the application.
>     If this code pattern is found then the lambda proxy class is not
>     included in the CDS archive.
>     See
>     https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L163-L170
>     <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L163-L170__;Iw!!ACWV5N9M2RV99hQ!M5PIaQwz6ZHuzVVtZJNYTX90hyGcXPERPk54_t8SkHB7Yx1MU18tVDgW5SHylTR4SuJU8Ob6LqcDmg$>
>     and
>     https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L246
>     <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L246__;Iw!!ACWV5N9M2RV99hQ!M5PIaQwz6ZHuzVVtZJNYTX90hyGcXPERPk54_t8SkHB7Yx1MU18tVDgW5SHylTR4SuJU8ObkWSEOJg$>
>
>     ? ? ? ? // If the target class invokes a protected method
>     inherited from a
>     ? ? ? ? // superclass in a different package, or does
>     'invokespecial', the
>     ? ? ? ? // lambda class has no access to the resolved method, or does
>     ? ? ? ? // 'invokestatic' on a hidden class which cannot be
>     resolved by name.
>     ? ? ? ? // Instead, we need to pass the live implementation method
>     handle to
>     ? ? ? ? // the proxy class to invoke directly. (javac prefers to
>     avoid this
>     ? ? ? ? // situation by generating bridges in the target class)
>     ? ? ? ? useImplMethodHandle =
>     (Modifier.isProtected(implInfo.getModifiers()) &&
>     ?!VerifyAccess.isSamePackage(targetClass,
>     implInfo.getDeclaringClass())) ||
>     ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?implKind ==
>     MethodHandleInfo.REF_invokeSpecial ||
>     ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?implKind ==
>     MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>
>     In premain lambda proxy classes get included in the AOT cache as a
>     result of indy resolution and that mechanism doesn't have this
>     kind of check.
>
>     3. For the null classData problem mentioned above, I tried to fix
>     it by storing classData in the scratch mirror using the following
>     patch:
>
>     diff --git a/src/hotspot/share/classfile/javaClasses.cpp
>     b/src/hotspot/share/classfile/javaClasses.cpp
>     index bd8141adbcc..41766e98093 100644
>     --- a/src/hotspot/share/classfile/javaClasses.cpp
>     +++ b/src/hotspot/share/classfile/javaClasses.cpp
>     @@ -1094,9 +1094,9 @@ void java_lang_Class::create_mirror(Klass*
>     k, Handle class_loader,
>     ? ? ?}
>     ? ? ?if (CDSConfig::is_dumping_heap()) {
>     ? ? ? ?if (CDSConfig::is_dumping_protection_domains()) {
>     - ? ? ? ?create_scratch_mirror(k, protection_domain, CHECK);
>     + ? ? ? ?create_scratch_mirror(k, protection_domain, classData,
>     CHECK);
>     ? ? ? ?} else {
>     - ? ? ? ?create_scratch_mirror(k, Handle() /* null
>     protection_domain*/, CHECK);
>     + ? ? ? ?create_scratch_mirror(k, Handle() /* null
>     protection_domain*/, classData, CHECK);
>     ? ? ? ?}
>     ? ? ?}
>     ? ?} else {
>     @@ -1117,7 +1117,7 @@ void java_lang_Class::create_mirror(Klass*
>     k, Handle class_loader,
>     ?// Note: we archive the "scratch mirror" instead of
>     k->java_mirror(), because the
>     ?// latter may contain dumptime-specific information that cannot
>     be archived
>     ?// (e.g., ClassLoaderData*, or static fields that are modified by
>     Java code execution).
>     -void java_lang_Class::create_scratch_mirror(Klass* k, Handle
>     protection_domain, TRAPS) {
>     +void java_lang_Class::create_scratch_mirror(Klass* k, Handle
>     protection_domain, Handle classData, TRAPS) {
>     ? ?if (k->class_loader() != nullptr &&
>     ? ? ? ?k->class_loader() !=
>     SystemDictionary::java_platform_loader() &&
>     ? ? ? ?k->class_loader() != SystemDictionary::java_system_loader()) {
>     @@ -1125,9 +1125,11 @@ void
>     java_lang_Class::create_scratch_mirror(Klass* k, Handle
>     protection_domain,
>     ? ? ?return;
>     ? ?}
>
>     - ?Handle classData; // set to null. Will be reinitialized at runtime
>     + ?//Handle classData; // set to null. Will be reinitialized at
>     runtime
>     ? ?Handle mirror;
>     ? ?Handle comp_mirror;
>     ? ?allocate_mirror(k, /*is_scratch=*/true, protection_domain,
>     classData, mirror, comp_mirror, CHECK);
>
>     ? ?if (comp_mirror() != nullptr) {
>     diff --git a/src/hotspot/share/classfile/javaClasses.hpp
>     b/src/hotspot/share/classfile/javaClasses.hpp
>     index bc49a0861a7..7ec2a2556dd 100644
>     --- a/src/hotspot/share/classfile/javaClasses.hpp
>     +++ b/src/hotspot/share/classfile/javaClasses.hpp
>     @@ -263,7 +263,7 @@ class java_lang_Class : AllStatic {
>
>     ? ?// Archiving
>     ? ?static void serialize_offsets(SerializeClosure* f) NOT_CDS_RETURN;
>     - ?static void create_scratch_mirror(Klass* k, Handle
>     protection_domain, TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>     + ?static void create_scratch_mirror(Klass* k, Handle
>     protection_domain, Handle classData, TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>     ? ?static bool restore_archived_mirror(Klass *k, Handle
>     class_loader, Handle module,
>     ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Handle protection_domain,
>     ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?TRAPS)
>     NOT_CDS_JAVA_HEAP_RETURN_(false);
>
>     But this resulted in a different exception:
>
>     Exception in thread "main" java.lang.ExceptionInInitializerError
>     at com.redhat.leyden.Main.main(Main.java:7)
>     Caused by: java.lang.invoke.WrongMethodTypeException: handle's
>     method type (WildFlyElytronBaseProvider,Service)void but found
>     (WildFlyElytronBaseProvider,Service)void
>     at
>     java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>     at
>     java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>     at
>     java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
>     at
>     org.wildfly.security.WildFlyElytronBaseProvider$$Lambda/0x80000000c.accept(Unknown
>     Source)
>     at
>     org.wildfly.security.WildFlyElytronBaseProvider.putMakedPasswordImplementations(WildFlyElytronBaseProvider.java:112)
>     at
>     org.wildfly.security.WildFlyElytronBaseProvider.putPasswordImplementations(WildFlyElytronBaseProvider.java:107)
>     at
>     org.wildfly.security.password.WildFlyElytronPasswordProvider.<init>(WildFlyElytronPasswordProvider.java:43)
>     at
>     org.wildfly.security.password.WildFlyElytronPasswordProvider.<clinit>(WildFlyElytronPasswordProvider.java:36)
>     ... 1 more
>
>     The exception message is strange because the handle's method type
>     and the expected type are both symbolically the same.
>     I am debugging this exception at the moment.
>     Thanks,
>     - Ashutosh Mehra
>
>
>     On Wed, Sep 11, 2024 at 6:03?AM Andrew Dinn <adinn at redhat.com> wrote:
>
>         Oops, sorry, I debugged this a few days ago! Correction to a
>         few details:
>
>         On 11/09/2024 10:39, Andrew Dinn wrote:
>         > A crash due to an NPE was observed in the Infinispan (Data
>         Grid) server
>         > app when deployed using the Leyden EA. The crash still
>         manifests with
>         > the latest premain code. The crash happens below an
>         application call
>         > which employs a method reference as argument
>         >
>         > putMakedPasswordImplementations(this::putService, this);
>
>         The called method in turn calls consumer.accept
>
>         ? ? ? ? ? ? ?consumer.accept(new Service(provider,
>         PASSWORD_FACTORY_TYPE, algorithm,
>         "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>         emptyList,
>         emptyMap));
>
>         which enters enters MethodHandleNative::linkDynamicConstant()
>
>         > Debugging shows that the call to linkDynamicConstant()
>         returns null.
>         >
>         > A simple reproducer for the problem is available as a maven
>         project on
>         > github:
>         >
>         > https://github.com/tristantarrant/elytron-leyden
>         <https://urldefense.com/v3/__https://github.com/tristantarrant/elytron-leyden__;!!ACWV5N9M2RV99hQ!M5PIaQwz6ZHuzVVtZJNYTX90hyGcXPERPk54_t8SkHB7Yx1MU18tVDgW5SHylTR4SuJU8OYVB3q3-A$>
>         >
>         > The ReadMe provides an explanation of how to reproduce the
>         problem. I
>         > did so and the debugged to find out some of the details of
>         what is
>         > happening (see below) but did not fully clarify the problem.
>         Help from
>         > someone more conversant with the ins and outs of method handle
>         > bootstraps in premain would be welcome. Details follow.
>         >
>         > regards,
>         >
>         >
>         > Andrew Dinn
>         > -----------
>         >
>         > I downloaded the git repo and attached the Java sources
>         using Maven command
>         >
>         >? ? $ mvn dependency:sources
>         >
>         > Having manifested the crash by following the instructions in
>         the README
>         > I reran the leyden JVM under gdb using the following
>         commands to enable
>         > Java debugging
>         >
>         > $ gdb ${LEYDEN_HOME}/bin/java
>         > (gdb) cd /path/to/mvn/project
>         > (gdb) run
>         >
>         -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
>
>         > -classpath
>         >
>         /home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/2.5.1.
>         <https://urldefense.com/v3/__http://2.5.1.__;!!ACWV5N9M2RV99hQ!M5PIaQwz6ZHuzVVtZJNYTX90hyGcXPERPk54_t8SkHB7Yx1MU18tVDgW5SHylTR4SuJU8OaYBVY__Q$>Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar
>         -XX:CacheDataStore=elytron.aot com.redhat.leyden.Main
>         >
>         > The problem manifests at WildflyElytronBaseProvider.java:112
>         in method
>         > WildflyElytronBaseProvider::putMakedPasswordImplementations
>
>         ? ? ?static void
>         putMakedPasswordImplementations(Consumer<Service>
>         consumer, Provider provider) {
>         ? ? ? ? ?for (String algorithm : MASKED_ALGORITHMS) {
>         ? ? ? ? ? ? ?consumer.accept(new Service(provider,
>         PASSWORD_FACTORY_TYPE, algorithm,
>         "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>         emptyList,
>         emptyMap)); <== NPE under this call
>         ? ? ? ? ?}
>
>
>         > The source code for this method can be found in the
>         following source jar
>         >
>         >
>         >
>         ${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar
>         >
>         > (where M2_REPO will normally be ~/.m2/repository)
>         >
>         > Stepping into accept eventually enters
>         MethodHandleNative::linkDynamicConstant
>         > which in turn enters into ConstantBootstraps.makeConstant().
>         The caller
>         > Class at this point is a lambda class which prints as
>         >
>         org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c
>         >
>         > Several steps further the code enters
>         BootstrapMethodInvoker::invoke
>         > (below the app method call but via 3 hidden frames) with
>         bootstrapMethod
>         > bound to a DirectMethodHandle. After several more steps this
>         enters
>         > DirectMethodHandle$Holder.invokeStatic which in turn calls
>         > MethodHandles::classData(Lookup,String,Class).
>         >
>         > At this point caller is a MethodHandleLookup for the lambda
>         class
>         > Lambda/0x800000000c mentioned above. The following call
>         >
>         >? ???????? Object classdata = classData(caller.lookupClass());
>         >
>         > returns null to DirectMethodHandle$Holder.invokeStatic which
>         pops the
>         > same result back out to BootstrapMethodInvoker::invoke at
>         line 90
>         >
>         >? ??????????????? if (type instanceof Class<?> c) {
>         >? ??????????????????? result = bootstrapMethod.invoke(caller,
>         name, c);
>         > <== null
>         >
>         > This null result pops back out as the value for the call to
>         > BootstrapMethodInvoker.invoke(),
>         ConstantBootstraps.makeConstant() and
>         > MethodHandleNative::linkDynamicConstant().
>         >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240911/434009a0/attachment.htm>

From ioi.lam at oracle.com  Thu Sep 12 03:32:22 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Wed, 11 Sep 2024 20:32:22 -0700
Subject: RFR: 8293187: Store initialized Enum classes in AOTCache
Message-ID: <28223eea-687b-44c3-a681-8106dd403a9d@oracle.com>

Hi, this is the 4th PR for JEP 483 - Ahead-of-Time Class Loading & 
Linking [1]

The PR is https://github.com/openjdk/jdk/pull/20958

The following are added in this PR

- support for archiving sun.invoke.util.Wrapper enums. This is a 
preliminary step for archiving LambdaForms.

- the ability to store classes in initialized state. This PR does it for 
enums and a few other classes. More classes will be added to the 
aot-init list in subsequent PRs.


The plan [2] is to break down JEP 483 in a series of 7 PRs to make it 
easier to review. I will post the other PRs soon.

Thanks

- Ioi

===

[1] https://openjdk.org/jeps/483
[2] https://bugs.openjdk.org/browse/JDK-8331497


From sebastien.deleuze at broadcom.com  Thu Sep 12 08:21:32 2024
From: sebastien.deleuze at broadcom.com (Sebastien Deleuze)
Date: Thu, 12 Sep 2024 10:21:32 +0200
Subject: premain: CGLIB error during the training run with Petclinic
In-Reply-To: <93e83e4d-b75a-4c75-8935-08e4697cade7@oracle.com>
References: <CAG5jep_f8Ne8wRBEfD9hHB7TzLB-Axip6Yrnc6rz0SobgALOZw@mail.gmail.com>
 <a8fd083c-4731-446e-9117-9898e8fe9fef@oracle.com>
 <CAG5jep--vGCe--6FeOTiG_m4Ye+3JtHYBTfQA5mygDjPMYQsdg@mail.gmail.com>
 <4c7c879e-1488-41a8-a8e0-97d9f1379687@oracle.com>
 <CAG5jep8kCfuFELbN3T=aZds3=UvMCWL64LrD=yPd58KYJXHaPA@mail.gmail.com>
 <93e83e4d-b75a-4c75-8935-08e4697cade7@oracle.com>
Message-ID: <CAG5jep_R=ONowGHhZu2YXrT_f2jzsUGCFjWbsuuu7fKpFEo4kg@mail.gmail.com>

I confirm that the first java command triggers the error while the second
one does not, so the error looks indeed triggered by the extra work
performed by the VM for collecting profiling information.

FYI I tried to reproduce with
https://github.com/spring-projects/spring-petclinic which is the JPA
variant of Petclinic you are already using, but was unable to reproduce, so
I guess you will need to use and adapt the Spring Data JDBC variant
available at https://github.com/sdeleuze/petclinic-efficient-container and
request http://localhost:8080/owners if you want to debug this more
precisely.

On Thu, Sep 12, 2024 at 5:07?AM <ioi.lam at oracle.com> wrote:

> It seems like the error happens only when running in "training mode". Can
> you try something like this to isolate the problem?
>
>     rm -f app.cds
>     java -cp app.jar -XX:CacheDataStore -XX:+UnlockDiagnosticVMOptions
> -XX:+CDSManualFinalImage AppMain
>
> This will make sure that the app is executed with profile collection
> enabled. The profile is written to the file foo.cds.preimage.
>
> Normally, after foo.cds.preimage is created, we fork a sub process to
> consume foo.cds.preimage and write foo.cds.  -XX:+CDSManualFinalImage
> prevents the sub process from being created.
>
> If the above causes an error, but this doesn't (when running the exact
> same workload)
>
>     java -cp app.jar -Xshare:off AppMain
>
> then we know that the error is triggered by the extra work performed by
> the VM for collecting profiling information.
>
> Thanks
>
> - Ioi
> On 9/11/24 6:02 AM, Sebastien Deleuze wrote:
>
> After adding more logging, I can confirm the original exception when
> -XX:CacheDataStore is set with no existing CDS file is thrown by
> MethodHandles.Lookup#defineClass and is similar to the second one I
> reported.
> This is a class that Spring Data generates during runtime.
>
> java.lang.VerifyError: Bad local variable type
> Exception Details:
>   Location:
>
> org/springframework/samples/petclinic/owner/Owner_Accessor_yw4ckn.getProperty(Lorg/springframework/data/mapping/PersistentProperty;)Ljava/lang/Object;
> @83: aload_2
>   Reason:
>     Type top (current frame, locals[2]) is not assignable to reference type
>   Current Frame:
>     bci: @83
>     flags: { }
>     locals: {
> 'org/springframework/samples/petclinic/owner/Owner_Accessor_yw4ckn',
> 'org/springframework/data/mapping/PersistentProperty' }
>     stack: { 'java/lang/invoke/MethodHandle' }
>   Bytecode:
>     0000000: 2b12 7db8 0027 2ab4 0029 4d2b b900 8301
>     0000010: 00b6 0089 ab00 0000 0000 006c 0000 0006
>     0000020: a900 4641 0000 004c bb97 9bf4 0000 0054
>     0000030: 0000 0d1b 0000 003c 002e 996b 0000 005c
>     0000040: 07ea e95b 0000 0044 2eae b404 0000 0064
>     0000050: b200 4a2c b600 a5b0 b200 532c b600 a5b0
>     0000060: b200 592c b600 a5b0 b200 5f2c b600 a5b0
>     0000070: b200 652c b600 a5b0 b200 6b2c b600 a5b0
>     0000080: bb00 9159 12a7 04bd 0004 5903 2b53 b800
>     0000090: 97b7 009a bf
>   Stackmap Table:
>     same_frame_extended(@80)
>     same_frame(@88)
>     same_frame(@96)
>     same_frame(@104)
>     same_frame(@112)
>     same_frame(@120)
>     same_frame(@128)
>
> I have shared the related output I get with -Xlog:exceptions on
> https://gist.github.com/sdeleuze/96e638dd3bb94918c545ee54fca9b8a3 in case
> that could be useful.
>
>
> On Wed, Sep 11, 2024 at 2:51?PM Alan Bateman <alan.bateman at oracle.com>
> wrote:
>
>> On 11/09/2024 13:16, Sebastien Deleuze wrote:
>> > Yes, it works without --add-opens and without -XX:CacheDataStore, in
>> > all my use cases I never set --add-opens explicitly.
>> >
>> > There are various fallback paths, and potentially the original
>> > exception is hidden, so let me have a deeper look by comparing broken
>> > and successful code paths.
>> > I will share more details in an upcoming email.
>> >
>> Maybe running with -Xlog:exceptions might reveal something.
>>
>> -Alan
>>
>
> This electronic communication and the information and any files
> transmitted with it, or attached to it, are confidential and are intended
> solely for the use of the individual or entity to whom it is addressed and
> may contain information that is confidential, legally privileged, protected
> by privacy laws, or otherwise restricted from disclosure to anyone else. If
> you are not the intended recipient or the person responsible for delivering
> the e-mail to the intended recipient, you are hereby notified that any use,
> copying, distributing, dissemination, forwarding, printing, or copying of
> this e-mail is strictly prohibited. If you received this e-mail in error,
> please return the e-mail to the sender, delete it from your computer, and
> destroy any printed copy of it.
>
>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240912/cfeeb424/attachment.htm>

From duke at openjdk.org  Thu Sep 12 16:47:26 2024
From: duke at openjdk.org (duke)
Date: Thu, 12 Sep 2024 16:47:26 GMT
Subject: git: openjdk/leyden: premain: Tidy up
Message-ID: <af60b161-3f45-4bfc-ad6f-78f5558e44b2@openjdk.org>

Changeset: 07ad2086
Branch: premain
Author:    Igor Veresov <igor.veresov at oracle.com>
Date:      2024-09-12 09:44:31 +0000
URL:       https://git.openjdk.org/leyden/commit/07ad2086bdac70ac2fd87876a68906519cf799b8

Tidy up

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


From kvn at openjdk.org  Thu Sep 12 17:12:20 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 12 Sep 2024 17:12:20 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v2]
In-Reply-To: <shiGolUnmKfaNTi1qlO-P0TD7pASS1QgVyMLU5AZxpg=.189f8b78-ac35-40fb-ac9d-31714e050581@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
 <shiGolUnmKfaNTi1qlO-P0TD7pASS1QgVyMLU5AZxpg=.189f8b78-ac35-40fb-ac9d-31714e050581@github.com>
Message-ID: <bqoPZLczn8_BhPtG1ZoPBkQo1mwuvg8dLYnlmCH1j_4=.31be8780-21ed-4f2f-b1e3-359efd57cc58@github.com>

On Wed, 11 Sep 2024 14:45:58 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> This PR modifies AOT compiled method code to load compressed oops base and shift constants via the AOTRuntimeConstants area rather than encode them as immediates. It also unlatches the currently forced setting of UseCompatibleCompressedOops, allowing the heap to be allocated wherever it will fit.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   only check UseCompatibleCompressedOops on 64 bit builds

src/hotspot/cpu/aarch64/aarch64.ad line 5175:

> 5173: operand indirectN(iRegN reg)
> 5174: %{
> 5175:   predicate(CompressedOops::shift() == 0 && !SCCache::is_on_for_write());

Does it imply that with SCC is on_write we will not have the shift == 0?

src/hotspot/share/code/SCCache.cpp line 682:

> 680:   if (UseCompatibleCompressedOops && (_compressedOopShift != (uint)CompressedOops::shift())) {
> 681:     log_warning(scc, init)("Disable Startup Code Cache: '%s' was created with CompressedOops::shift() = %d vs current %d and UseCompatibleCompressedOops=%s", cache_path, _compressedOopShift, CompressedOops::shift(),
> 682:                            UseCompatibleCompressedOops ? "true" : "false");

Why print flags value when you check it in the condition - it will be `true`

src/hotspot/share/code/SCCache.hpp line 621:

> 619:   uint _grain_shift;
> 620:   uint _card_shift;
> 621:   address _coops_base;

Move `address` first for better fields alignment

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/20#discussion_r1757268153
PR Review Comment: https://git.openjdk.org/leyden/pull/20#discussion_r1757265220
PR Review Comment: https://git.openjdk.org/leyden/pull/20#discussion_r1757257861

From macarte at openjdk.org  Thu Sep 12 17:38:20 2024
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 12 Sep 2024 17:38:20 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v3]
In-Reply-To: <sGbZxClkC1gVEtSjILXVTarW-ns_8Vv3Ylgbgq7rLqY=.29b21ee8-da43-44d8-b882-e194f4a79cb3@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
 <sGbZxClkC1gVEtSjILXVTarW-ns_8Vv3Ylgbgq7rLqY=.29b21ee8-da43-44d8-b882-e194f4a79cb3@github.com>
Message-ID: <XGXLVDzhpqxG3ouwhFzchZTczFykwJvyIeBcMkkjCxI=.8e31f6dc-d961-4a05-a88e-230898b0563f@github.com>

On Wed, 11 Sep 2024 22:24:53 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> AOT training can be ended using either
>> 
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
>> - jcmd <pid> AOT.end_training
>> 
>> supports arm64 and x64
>> 
>> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
>> 
>> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   another missing include that impacts some build configurations

src/hotspot/share/services/diagnosticCommand.hpp line 410:

> 408:     static const JavaPermission permission() {
> 409:     JavaPermission p = {"java.lang.management.ManagementPermission",
> 410:                         "monitor", nullptr};

Should this be 'monitor' or 'control' (or something else)?

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1757301959

From iklam at openjdk.org  Thu Sep 12 18:19:21 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 12 Sep 2024 18:19:21 GMT
Subject: RFR: Rework rich PrintCompilation logs [v2]
In-Reply-To: <nCKp32Rc6Ci2_9c9_YxEEqKsXQDeAUz9niNTP5CqpZA=.8c4c360b-85b1-4b0d-b22a-7d787e893ae3@github.com>
References: <zLhCmUJJNvTtr0OlHLVB-VhCd6PZJOrEk-Tj0BYnho0=.35fcaefe-4b14-492a-ab81-52dee3fef653@github.com>
 <nCKp32Rc6Ci2_9c9_YxEEqKsXQDeAUz9niNTP5CqpZA=.8c4c360b-85b1-4b0d-b22a-7d787e893ae3@github.com>
Message-ID: <0jXupao9iaHJoW3Odqde_RvaL4sfdhhHac1Y7wrxiY0=.9f67fcdc-1841-43e1-a80d-8138cb0d2628@github.com>

On Fri, 6 Sep 2024 19:54:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have been studying javac benchmark behavior, and current `PrintCompilation` logs are very useful to figure out how much time is spent in creation, queueing, work time for each task. Current logs are quite a bit confusing, though:
>>  - The columns are misindented
>>  - The precision is too low to capture short events: most of the times are zero
>>  - Output seems to rely on "now" timestamp, which depends on _when_ we print
>>  
>> This PR reworks the logs to be more straightforward.
>> 
>> Example before:
>> 
>> 
>>    S296 C0 Q229 3531      A  2       com.sun.tools.javac.parser.JavacParser::typeName (37 bytes)
>>    S296 C0 Q245 2030      A  2       com.sun.tools.javac.tree.TreeInfo::innermostType (102 bytes)
>>    S296 C0 Q0 4169         3       com.sun.tools.javac.comp.Flow$AliveAnalyzer$$Lambda/0x800000105::accept (12 bytes)
>>    S296 C0 Q245 2042      A  2       com.sun.tools.javac.tree.JCTree$JCPrimitiveTypeTree::accept (9 bytes)
>>    S296 C0 Q0 4170         3       com.sun.tools.javac.comp.Flow$AssignAnalyzer$$Lambda/0x800000108::accept (12 bytes)
>>    S296 C0 Q0 4171         3       com.sun.tools.javac.comp.Flow$FlowAnalyzer$$Lambda/0x80000010a::accept (12 bytes)
>>    S296 C0 Q245 2098      A  2       com.sun.tools.javac.code.Symbol$RecordComponent::getOriginalAnnos (24 bytes)
>>    S296 C0 Q244 2348      A  2       com.sun.tools.javac.tree.TreeCopier::visitPrimitiveType (24 bytes)
>>    S296 C0 Q244 2349      A  2       com.sun.tools.javac.tree.TreeCopier::visitPrimitiveType (7 bytes)
>> 
>> 
>> Example after:
>> 
>> 
>>     386    W0.0  Q313.7    C0.2   3524   !  A  2       com.sun.tools.javac.parser.JavacParser::literal (655 bytes)
>>     386                           3858         3       java.util.stream.MatchOps$$Lambda/0x800000030::<init> (15 bytes)   made not entrant
>>     386    W0.1                   2416      A  1       com.sun.tools.javac.comp.Infer$CheckInst::boundsToCheck (5 bytes)
>>     386    W0.0    Q0.1    C0.2   4155         4       java.util.stream.MatchOps$$Lambda/0x800000030::<init> (15 bytes)
>>     386    W0.1  Q332.7    C0.0   2416      A  1       com.sun.tools.javac.comp.Infer$CheckInst::boundsToCheck (5 bytes)
>>     386    W0.2                   2902      A  2       com.sun.tools.javac.code.ClassFinder::classFileNotFound (13 bytes)
>>     386    W0.2  Q327.9    C0.0   2902      A  2       com.sun.tools.javac.code.ClassFinder::classFileNotFound (13 bytes)
>>     386    W0.0                   3527      A  2       com.sun.tools.javac.parser.Java...
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Swap W<->C

Should some of this code be upstreamed to mainline?

-------------

PR Comment: https://git.openjdk.org/leyden/pull/16#issuecomment-2346950823

From macarte at openjdk.org  Thu Sep 12 18:55:21 2024
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 12 Sep 2024 18:55:21 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v3]
In-Reply-To: <sGbZxClkC1gVEtSjILXVTarW-ns_8Vv3Ylgbgq7rLqY=.29b21ee8-da43-44d8-b882-e194f4a79cb3@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
 <sGbZxClkC1gVEtSjILXVTarW-ns_8Vv3Ylgbgq7rLqY=.29b21ee8-da43-44d8-b882-e194f4a79cb3@github.com>
Message-ID: <ar5NhmtBpbGdoYLHjUG8zMizk6E98Na3i_0waUqowtM=.545985b4-bddc-4ef2-8510-211300c366c4@github.com>

On Wed, 11 Sep 2024 22:24:53 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> AOT training can be ended using either
>> 
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
>> - jcmd <pid> AOT.end_training
>> 
>> supports arm64 and x64
>> 
>> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
>> 
>> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   another missing include that impacts some build configurations

src/hotspot/share/interpreter/interpreterRuntime.cpp line 1163:

> 1161:   ResourceMark rm(current);
> 1162:   methodHandle m (current, last_frame.method());
> 1163:   if(m->is_end_training_trigger()) {

unlike c1 and c2, we need to check the method flag here, as the generated code is used for many methods and so has to be included in all interpreter methods

src/hotspot/share/runtime/sharedRuntime.cpp line 1415:

> 1413: 
> 1414: JRT_BLOCK_ENTRY(void, SharedRuntime::end_training_check_c2(JavaThread* current))
> 1415: {

this and the _c1 method don't need to check the method flag to see if its a 'trigger', this is because we checked that on code generation which predicates the call to these methods

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1757405331
PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1757404258

From asmehra at openjdk.org  Thu Sep 12 20:29:21 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 12 Sep 2024 20:29:21 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v2]
In-Reply-To: <bqoPZLczn8_BhPtG1ZoPBkQo1mwuvg8dLYnlmCH1j_4=.31be8780-21ed-4f2f-b1e3-359efd57cc58@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
 <shiGolUnmKfaNTi1qlO-P0TD7pASS1QgVyMLU5AZxpg=.189f8b78-ac35-40fb-ac9d-31714e050581@github.com>
 <bqoPZLczn8_BhPtG1ZoPBkQo1mwuvg8dLYnlmCH1j_4=.31be8780-21ed-4f2f-b1e3-359efd57cc58@github.com>
Message-ID: <6vUnp6ys59n9yv8f-ZgYvpH7saAj4cUJhQ3pTwyh1hM=.3c320d5f-369a-45bc-a319-aeceb5790ca3@github.com>

On Thu, 12 Sep 2024 17:09:50 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   only check UseCompatibleCompressedOops on 64 bit builds
>
> src/hotspot/cpu/aarch64/aarch64.ad line 5175:
> 
>> 5173: operand indirectN(iRegN reg)
>> 5174: %{
>> 5175:   predicate(CompressedOops::shift() == 0 && !SCCache::is_on_for_write());
> 
> Does it imply that with SCC is on_write we will not have the shift == 0?

No, this is to prevent the match when compiling AOT code. We don't want to generate any AOT code which depends on shift == 0 as it may change during runtime.

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/20#discussion_r1757538416

From kvn at openjdk.org  Thu Sep 12 20:52:15 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 12 Sep 2024 20:52:15 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v2]
In-Reply-To: <6vUnp6ys59n9yv8f-ZgYvpH7saAj4cUJhQ3pTwyh1hM=.3c320d5f-369a-45bc-a319-aeceb5790ca3@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
 <shiGolUnmKfaNTi1qlO-P0TD7pASS1QgVyMLU5AZxpg=.189f8b78-ac35-40fb-ac9d-31714e050581@github.com>
 <bqoPZLczn8_BhPtG1ZoPBkQo1mwuvg8dLYnlmCH1j_4=.31be8780-21ed-4f2f-b1e3-359efd57cc58@github.com>
 <6vUnp6ys59n9yv8f-ZgYvpH7saAj4cUJhQ3pTwyh1hM=.3c320d5f-369a-45bc-a319-aeceb5790ca3@github.com>
Message-ID: <Etrq87iPOcnDCa4DLKde7dD_jfGyv_rnnrvgqAU120s=.c52bd162-1f87-4b12-bb14-409043df44cb@github.com>

On Thu, 12 Sep 2024 20:26:23 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/aarch64.ad line 5175:
>> 
>>> 5173: operand indirectN(iRegN reg)
>>> 5174: %{
>>> 5175:   predicate(CompressedOops::shift() == 0 && !SCCache::is_on_for_write());
>> 
>> Does it imply that with SCC is on_write we will not have the shift == 0?
>
> No, this is to prevent the match when compiling AOT code. We don't want to generate any AOT code which depends on shift == 0 as it may change during runtime.

Okay.

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/20#discussion_r1757563343

From kvn at openjdk.org  Thu Sep 12 21:01:19 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 12 Sep 2024 21:01:19 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v2]
In-Reply-To: <shiGolUnmKfaNTi1qlO-P0TD7pASS1QgVyMLU5AZxpg=.189f8b78-ac35-40fb-ac9d-31714e050581@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
 <shiGolUnmKfaNTi1qlO-P0TD7pASS1QgVyMLU5AZxpg=.189f8b78-ac35-40fb-ac9d-31714e050581@github.com>
Message-ID: <OTFfYru4x10KfqpFQTgiCcUv_GX-COk8Aleb1fDMRkc=.84d04b36-f049-43a0-b7c2-e412a5c5de9a@github.com>

On Wed, 11 Sep 2024 14:45:58 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> This PR modifies AOT compiled method code to load compressed oops base and shift constants via the AOTRuntimeConstants area rather than encode them as immediates. It also unlatches the currently forced setting of UseCompatibleCompressedOops, allowing the heap to be allocated wherever it will fit.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   only check UseCompatibleCompressedOops on 64 bit builds

Sorry, I am not sure about these changes any more vs enabling unconditionally `UseCompatibleCompressedOops`.
You will always use these loads, even for simplest "Unscaled" case. The performance will be much worse than using enforced constant shift and base.

Did you run any performance testing?

-------------

PR Comment: https://git.openjdk.org/leyden/pull/20#issuecomment-2347229377

From kvn at openjdk.org  Thu Sep 12 23:16:18 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 12 Sep 2024 23:16:18 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v2]
In-Reply-To: <shiGolUnmKfaNTi1qlO-P0TD7pASS1QgVyMLU5AZxpg=.189f8b78-ac35-40fb-ac9d-31714e050581@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
 <shiGolUnmKfaNTi1qlO-P0TD7pASS1QgVyMLU5AZxpg=.189f8b78-ac35-40fb-ac9d-31714e050581@github.com>
Message-ID: <khnEAEVHg8y3-Q0dAiJN1WJ1aSFxm8bv0F1gyYDrUq4=.f0d1d6fc-d37f-40db-a4ee-7addb3ea92b9@github.com>

On Wed, 11 Sep 2024 14:45:58 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> This PR modifies AOT compiled method code to load compressed oops base and shift constants via the AOTRuntimeConstants area rather than encode them as immediates. It also unlatches the currently forced setting of UseCompatibleCompressedOops, allowing the heap to be allocated wherever it will fit.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   only check UseCompatibleCompressedOops on 64 bit builds

Thinking more.

On other hand, only AOT code will suffer. Recompiled code will be optimal which is good for peak performance.
And with UseCompatibleCompressedOops recompiled code will also suffer.

I need to see numbers how it affect performance of AOT code.  I hope CPU's prefetcher will keep these values nearby.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/20#issuecomment-2347393402

From shade at openjdk.org  Fri Sep 13 08:15:20 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 13 Sep 2024 08:15:20 GMT
Subject: RFR: Reformat internal profiling stats [v2]
In-Reply-To: <C0bEW0lvaGa8zdqAbPNTIwbi_N3BYkGQ9esQukmD3VY=.852a52f7-48f3-4568-86e5-a94194ef3a1a@github.com>
References: <BWF3jak3Q7K_pwiHDphZWkLr8SZAd73JcwKvuPprvYY=.c281cf2b-ffa6-46d3-972a-bf97ed119e33@github.com>
 <C0bEW0lvaGa8zdqAbPNTIwbi_N3BYkGQ9esQukmD3VY=.852a52f7-48f3-4568-86e5-a94194ef3a1a@github.com>
Message-ID: <p-K9mqkspuE9uvI5sYqRpCvHl6cI0KwO8S1lC7lvur8=.fa1d326f-3d87-471b-a257-a18427a4f40f@github.com>

On Mon, 9 Sep 2024 17:37:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> For HelloWorld/javac workloads, the current output resolution in milliseconds is not enough, we better off printing microseconds. Plus, indenting is not agreeing in interpreter/C1/C2 outputs, fixed that as well.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace

Anyone? @iklam, maybe?

-------------

PR Comment: https://git.openjdk.org/leyden/pull/18#issuecomment-2348313664

From shade at openjdk.org  Fri Sep 13 10:47:21 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 13 Sep 2024 10:47:21 GMT
Subject: RFR: Rework rich PrintCompilation logs [v2]
In-Reply-To: <0jXupao9iaHJoW3Odqde_RvaL4sfdhhHac1Y7wrxiY0=.9f67fcdc-1841-43e1-a80d-8138cb0d2628@github.com>
References: <zLhCmUJJNvTtr0OlHLVB-VhCd6PZJOrEk-Tj0BYnho0=.35fcaefe-4b14-492a-ab81-52dee3fef653@github.com>
 <nCKp32Rc6Ci2_9c9_YxEEqKsXQDeAUz9niNTP5CqpZA=.8c4c360b-85b1-4b0d-b22a-7d787e893ae3@github.com>
 <0jXupao9iaHJoW3Odqde_RvaL4sfdhhHac1Y7wrxiY0=.9f67fcdc-1841-43e1-a80d-8138cb0d2628@github.com>
Message-ID: <1UZCmsEbjvDnowKh-Sug7Rf_ZJQE_BmIfT5wH8zneHc=.8b563fcb-4f2b-4bd4-88b6-7b4b55961cd9@github.com>

On Thu, 12 Sep 2024 18:16:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Should some of this code be upstreamed to mainline?

Maybe? There are external tools like JITWatch that parse this output, though, so it would not be as simple. Let it be our performance tracking aid in Leyden for a little longer.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/16#issuecomment-2348634539

From kvn at openjdk.org  Fri Sep 13 16:49:30 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 13 Sep 2024 16:49:30 GMT
Subject: RFR: Rework rich PrintCompilation logs [v2]
In-Reply-To: <1UZCmsEbjvDnowKh-Sug7Rf_ZJQE_BmIfT5wH8zneHc=.8b563fcb-4f2b-4bd4-88b6-7b4b55961cd9@github.com>
References: <zLhCmUJJNvTtr0OlHLVB-VhCd6PZJOrEk-Tj0BYnho0=.35fcaefe-4b14-492a-ab81-52dee3fef653@github.com>
 <nCKp32Rc6Ci2_9c9_YxEEqKsXQDeAUz9niNTP5CqpZA=.8c4c360b-85b1-4b0d-b22a-7d787e893ae3@github.com>
 <0jXupao9iaHJoW3Odqde_RvaL4sfdhhHac1Y7wrxiY0=.9f67fcdc-1841-43e1-a80d-8138cb0d2628@github.com>
 <1UZCmsEbjvDnowKh-Sug7Rf_ZJQE_BmIfT5wH8zneHc=.8b563fcb-4f2b-4bd4-88b6-7b4b55961cd9@github.com>
Message-ID: <vR2QtLN8Qm5yT2MltIWbfrYdYTemqJswN94DNgjCyv0=.e503604f-962e-4958-b58b-5e91fa895f4a@github.com>

On Fri, 13 Sep 2024 10:44:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Should some of this code be upstreamed to mainline?
> 
> Maybe? There are external tools like JITWatch that parse this output, though, so it would not be as simple. Let it be our performance tracking aid in Leyden for a little longer.

Yes, lets keep it in premain for now.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/16#issuecomment-2349385708

From kvn at openjdk.org  Fri Sep 13 19:43:20 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 13 Sep 2024 19:43:20 GMT
Subject: RFR: Reformat internal profiling stats [v2]
In-Reply-To: <C0bEW0lvaGa8zdqAbPNTIwbi_N3BYkGQ9esQukmD3VY=.852a52f7-48f3-4568-86e5-a94194ef3a1a@github.com>
References: <BWF3jak3Q7K_pwiHDphZWkLr8SZAd73JcwKvuPprvYY=.c281cf2b-ffa6-46d3-972a-bf97ed119e33@github.com>
 <C0bEW0lvaGa8zdqAbPNTIwbi_N3BYkGQ9esQukmD3VY=.852a52f7-48f3-4568-86e5-a94194ef3a1a@github.com>
Message-ID: <BsMbm2MfAtp1txMWib2yqX67gdxy4Es_aLoetruyXSk=.e756e90d-499b-48c4-a1bd-b5b6090d9b36@github.com>

On Mon, 9 Sep 2024 17:37:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> For HelloWorld/javac workloads, the current output resolution in milliseconds is not enough, we better off printing microseconds. Plus, indenting is not agreeing in interpreter/C1/C2 outputs, fixed that as well.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace

Good.
I also noticed that `ms` is not enough.

-------------

Marked as reviewed by kvn (Committer).

PR Review: https://git.openjdk.org/leyden/pull/18#pullrequestreview-2303968424

From asmehra at redhat.com  Sat Sep 14 02:05:19 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Fri, 13 Sep 2024 22:05:19 -0400
Subject: premain: Crash in Infinispan server code caused by NPE under
 MethodHandleNative::linkDynamicConstant
In-Reply-To: <CAKt0pyQ44E+npyUW35Zhxg+PfBgF2yuNgS61gj1GGj=aLGTJXw@mail.gmail.com>
References: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
 <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>
 <CAKt0pySztvwsadtrqjai6XwakAWq_v_o8men4aopLo4X-0azyQ@mail.gmail.com>
 <CAKt0pyQ44E+npyUW35Zhxg+PfBgF2yuNgS61gj1GGj=aLGTJXw@mail.gmail.com>
Message-ID: <CAKt0pyT48uPH6rUL7bEJ2rtWqNdNL34DWBJ2SDaHwYfVxURnQw@mail.gmail.com>

This is turning out to be a real example of class initialization soup!
As mentioned during the meeting, I am getting NPE in the assembly phase
when testing the patch [0] that I proposed in my earlier mail
using a test case inspired by the Infinispan code.
NPE occurs when running the class initializer for PrimitiveClassDescImpl
Interestingly, PrimitiveClassDescImpl is "forcefully" initialized by
MetaspaceShared::link_shared_classes().

I couldn't get a stack trace so I relied on exception logs (using
-Xlog:exceptions=trace) to find the cause which indicate following frames
on the stack:

[0]
jdk/internal/constant/MethodTypeDescImpl::validateArgument(Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/ClassDesc;
@
bci 1
[1]
jdk/internal/constant/MethodTypeDescImpl::ofTrusted(Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljdk/internal/constant/MethodTypeDescImpl;
@
bci 27
[2]
java/lang/constant/ConstantDescs::ofConstantBootstrap(Ljava/lang/constant/ClassDesc;Ljava/lang/String;Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/DirectMethodHandleDesc;
@
bci 47
[3] java/lang/constant/ConstantDescs::<clinit> @ bci 664
[4]
jdk/internal/constant/PrimitiveClassDescImpl::<init>(Ljava/lang/String;)V @
bci 1
[5]
jdk/internal/constant/PrimitiveClassDescImpl::<clinit>(Ljava/lang/String;)V @
bci 6

Notice that invocation of PrimitiveClassDescImpl::<clinit> results in
initialization of ConstantDescs class (see frame 3).
ConstantDescs::<clinit> @ 664 corresponds to following java code:

    public static final DirectMethodHandleDesc BSM_CLASS_DATA_AT
            = ofConstantBootstrap(CD_MethodHandles, "classDataAt",
            CD_Object, CD_int);

The last parameter CD_int is initialized as:

    public static final ClassDesc CD_int = PrimitiveClassDescImpl.CD_int;

So, its value is obtained from PrimitiveClassDescImpl.CD_int which hasn't
been initialized properly yet. As a result ConstantDescs::CD_int is
assigned null
which results in MethodTypeDescImpl::validateArgument throwing NPE later.
There is a clear class initialization circularity involving
PrimitiveClassDescImpl and ConstantDescs, and the result depends on which
class gets initialized first.

Without my patch this issue is not seen because PrimitiveClassDescImpl has
already been initialized by the time MetaspaceShared::link_shared_classes() is
called.
Its initialization is triggered by the call to
MethodType::createArchivedObjects().
It also explains why my patch introduced this issue because it effectively
moved the call to MethodType::createArchivedObjects() after
MetaspaceShared::link_shared_classes().

[0]
https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e

Thanks,
- Ashutosh Mehra


On Wed, Sep 11, 2024 at 3:12?PM Ashutosh Mehra <asmehra at redhat.com> wrote:

> Regarding the WrongMethodTypeException that I mentioned in my previous
> email (see pt 3),
> this exception happens when lambda proxy class attempts to invoke the
> MethodHandle it obtained from the classData:
>
>   public void accept(java.lang.Object);
>     descriptor: (Ljava/lang/Object;)V
>     flags: (0x0001) ACC_PUBLIC
>     Code:
>       stack=3, locals=2, args_size=2
>          0: ldc           #26                 // Dynamic
> #0:_:Ljava/lang/invoke/MethodHandle;
>          2: aload_0
>          3: getfield      #13                 // Field
> arg$1:Lorg/wildfly/security/WildFlyElytronBaseProvider;
>          6: aload_1
>          7: checkcast     #28                 // class
> java/security/Provider$Service
>         10: invokevirtual #34                 // Method
> java/lang/invoke/MethodHandle.invokeExact:(Lorg/wildfly/security/WildFlyElytronBaseProvider;Ljava/security/Provider$Service;)V
>         13: return
>
> The scenario is during the assembly phase as part of the indy resolution
> the MethodHandle for which the exception is thrown gets created.
> Normally MethodHandle's type gets added in MethodType::internTable but by
> the time indy resolution happens, JVM has already taken
> snapshot of the MethodType::internTable through an upcall to
> MethodType::createArchivedObjects().
> As a result the AOTCache ends up with the MethodType object which is not
> in AOTHolder.archivedMethodTypes.
>
> During the production run, when the jvm invokes the MethodHandle, it
> searches for the MethodType corresponding to the signature passed at the
> callsite.
> As expected, it fails to find it in the AOTHolder.archivedMethodTypes, so
> it creates a new instance of the MethodType.
> But Invokers.checkExactType() relies on the MethodHandle's type to be the
> same object as the MethodType object passed as parameter.
>
>     static void checkExactType(MethodHandle mhM, MethodType expected) {
>         MethodType targetType = mh.type();
>         if (targetType != expected)
>             throw newWrongMethodTypeException(targetType, expected);
>     }
>
> Hence, it throws WrongMethodTypeException though the two MT objects have
> the same signature.
>
> To handle this scenario, I changed the order of indy resolution and upcall
> to MethodType::createArchivedObjects() as:
>
> diff --git a/src/hotspot/share/cds/metaspaceShared.cpp
> b/src/hotspot/share/cds/metaspaceShared.cpp
> index df4bcadefa3..457716cac5b 100644
> --- a/src/hotspot/share/cds/metaspaceShared.cpp
> +++ b/src/hotspot/share/cds/metaspaceShared.cpp
> @@ -751,6 +751,20 @@ void MetaspaceShared::link_shared_classes(bool
> jcmd_request, TRAPS) {
>    if (CDSConfig::is_dumping_final_static_archive()) {
>      FinalImageRecipes::apply_recipes(CHECK);
>    }
> +
> +#if INCLUDE_CDS_JAVA_HEAP
> +  if (CDSConfig::is_dumping_invokedynamic()) {
> +    // This makes sure that the MethodType and MethodTypeForm tables
> won't be updated
> +    // concurrently when we are saving their contents into a side table.
> +    assert(CDSConfig::allow_only_single_java_thread(), "Required");
> +
> +    JavaValue result(T_VOID);
> +    JavaCalls::call_static(&result, vmClasses::MethodType_klass(),
> +                           vmSymbols::createArchivedObjects(),
> +                           vmSymbols::void_method_signature(),
> +                           CHECK);
> +  }
> +#endif
>  }
>
> Note that indy resolution happens as part of FinalImageRecipes::apply_recipes(CHECK)
> which is now invoked before the upcall to createArchivedObjects().
> With this change I am able to run the application without any exceptions.
> My complete patch can be seen here:
> https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
> I will do more testing with this patch.
>
> @Ioi Lam <ioi.lam at oracle.com> do you have any feedback on this patch.
>
> Thanks,
> - Ashutosh Mehra
>
>
>
> On Wed, Sep 11, 2024 at 10:14?AM Ashutosh Mehra <asmehra at redhat.com>
> wrote:
>
>> Hi Andrew,
>> Thanks for sharing the initial investigation.
>> I have been looking into this and have a few of things to add to your
>> analysis:
>>
>> 1.  As you mentioned the classData for the lambda
>> class WildFlyElytronBaseProvider$$Lambda is null.
>> The classData is stored in the mirror object of the InstanceKlass when
>> the class is defined through JVM_LookupDefineClass.
>> However, when we create the scratch mirror object (which get stored in
>> the AOT cache) the classData is not populated.
>> See
>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp#L1128-L1131
>>
>>   Handle classData; // set to null. Will be reinitialized at runtime
>>   Handle mirror;
>>   Handle comp_mirror;
>>   allocate_mirror(k, /*is_scratch=*/true, protection_domain, classData,
>> mirror, comp_mirror, CHECK);
>>
>> So this explains why the call to classData(caller.lookupClass())
>> returned null.
>>
>> 2. In the mainline there is a check in InnerClassLambdaMetafactory.java
>> for the particular code pattern used by the application.
>> If this code pattern is found then the lambda proxy class is not included
>> in the CDS archive.
>> See
>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L163-L170
>> and
>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L246
>>
>>         // If the target class invokes a protected method inherited from a
>>         // superclass in a different package, or does 'invokespecial', the
>>         // lambda class has no access to the resolved method, or does
>>         // 'invokestatic' on a hidden class which cannot be resolved by
>> name.
>>         // Instead, we need to pass the live implementation method handle
>> to
>>         // the proxy class to invoke directly. (javac prefers to avoid
>> this
>>         // situation by generating bridges in the target class)
>>         useImplMethodHandle =
>> (Modifier.isProtected(implInfo.getModifiers()) &&
>>                                !VerifyAccess.isSamePackage(targetClass,
>> implInfo.getDeclaringClass())) ||
>>                                implKind ==
>> MethodHandleInfo.REF_invokeSpecial ||
>>                                implKind ==
>> MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>>
>> In premain lambda proxy classes get included in the AOT cache as a result
>> of indy resolution and that mechanism doesn't have this kind of check.
>>
>> 3. For the null classData problem mentioned above, I tried to fix it by
>> storing classData in the scratch mirror using the following patch:
>>
>> diff --git a/src/hotspot/share/classfile/javaClasses.cpp
>> b/src/hotspot/share/classfile/javaClasses.cpp
>> index bd8141adbcc..41766e98093 100644
>> --- a/src/hotspot/share/classfile/javaClasses.cpp
>> +++ b/src/hotspot/share/classfile/javaClasses.cpp
>> @@ -1094,9 +1094,9 @@ void java_lang_Class::create_mirror(Klass* k,
>> Handle class_loader,
>>      }
>>      if (CDSConfig::is_dumping_heap()) {
>>        if (CDSConfig::is_dumping_protection_domains()) {
>> -        create_scratch_mirror(k, protection_domain, CHECK);
>> +        create_scratch_mirror(k, protection_domain, classData, CHECK);
>>        } else {
>> -        create_scratch_mirror(k, Handle() /* null protection_domain*/,
>> CHECK);
>> +        create_scratch_mirror(k, Handle() /* null protection_domain*/,
>> classData, CHECK);
>>        }
>>      }
>>    } else {
>> @@ -1117,7 +1117,7 @@ void java_lang_Class::create_mirror(Klass* k,
>> Handle class_loader,
>>  // Note: we archive the "scratch mirror" instead of k->java_mirror(),
>> because the
>>  // latter may contain dumptime-specific information that cannot be
>> archived
>>  // (e.g., ClassLoaderData*, or static fields that are modified by Java
>> code execution).
>> -void java_lang_Class::create_scratch_mirror(Klass* k, Handle
>> protection_domain, TRAPS) {
>> +void java_lang_Class::create_scratch_mirror(Klass* k, Handle
>> protection_domain, Handle classData, TRAPS) {
>>    if (k->class_loader() != nullptr &&
>>        k->class_loader() != SystemDictionary::java_platform_loader() &&
>>        k->class_loader() != SystemDictionary::java_system_loader()) {
>> @@ -1125,9 +1125,11 @@ void java_lang_Class::create_scratch_mirror(Klass*
>> k, Handle protection_domain,
>>      return;
>>    }
>>
>> -  Handle classData; // set to null. Will be reinitialized at runtime
>> +  //Handle classData; // set to null. Will be reinitialized at runtime
>>    Handle mirror;
>>    Handle comp_mirror;
>>    allocate_mirror(k, /*is_scratch=*/true, protection_domain, classData,
>> mirror, comp_mirror, CHECK);
>>
>>    if (comp_mirror() != nullptr) {
>> diff --git a/src/hotspot/share/classfile/javaClasses.hpp
>> b/src/hotspot/share/classfile/javaClasses.hpp
>> index bc49a0861a7..7ec2a2556dd 100644
>> --- a/src/hotspot/share/classfile/javaClasses.hpp
>> +++ b/src/hotspot/share/classfile/javaClasses.hpp
>> @@ -263,7 +263,7 @@ class java_lang_Class : AllStatic {
>>
>>    // Archiving
>>    static void serialize_offsets(SerializeClosure* f) NOT_CDS_RETURN;
>> -  static void create_scratch_mirror(Klass* k, Handle protection_domain,
>> TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>> +  static void create_scratch_mirror(Klass* k, Handle protection_domain,
>> Handle classData, TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>>    static bool restore_archived_mirror(Klass *k, Handle class_loader,
>> Handle module,
>>                                        Handle protection_domain,
>>                                        TRAPS)
>> NOT_CDS_JAVA_HEAP_RETURN_(false);
>>
>> But this resulted in a different exception:
>>
>> Exception in thread "main" java.lang.ExceptionInInitializerError
>> at com.redhat.leyden.Main.main(Main.java:7)
>> Caused by: java.lang.invoke.WrongMethodTypeException: handle's method
>> type (WildFlyElytronBaseProvider,Service)void but found
>> (WildFlyElytronBaseProvider,Service)void
>> at
>> java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>> at java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>> at
>> java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
>> at
>> org.wildfly.security.WildFlyElytronBaseProvider$$Lambda/0x80000000c.accept(Unknown
>> Source)
>> at
>> org.wildfly.security.WildFlyElytronBaseProvider.putMakedPasswordImplementations(WildFlyElytronBaseProvider.java:112)
>> at
>> org.wildfly.security.WildFlyElytronBaseProvider.putPasswordImplementations(WildFlyElytronBaseProvider.java:107)
>> at
>> org.wildfly.security.password.WildFlyElytronPasswordProvider.<init>(WildFlyElytronPasswordProvider.java:43)
>> at
>> org.wildfly.security.password.WildFlyElytronPasswordProvider.<clinit>(WildFlyElytronPasswordProvider.java:36)
>> ... 1 more
>>
>> The exception message is strange because the handle's method type and the
>> expected type are both symbolically the same.
>> I am debugging this exception at the moment.
>>
>> Thanks,
>> - Ashutosh Mehra
>>
>>
>> On Wed, Sep 11, 2024 at 6:03?AM Andrew Dinn <adinn at redhat.com> wrote:
>>
>>> Oops, sorry, I debugged this a few days ago! Correction to a few details:
>>>
>>> On 11/09/2024 10:39, Andrew Dinn wrote:
>>> > A crash due to an NPE was observed in the Infinispan (Data Grid)
>>> server
>>> > app when deployed using the Leyden EA. The crash still manifests with
>>> > the latest premain code. The crash happens below an application call
>>> > which employs a method reference as argument
>>> >
>>> >          putMakedPasswordImplementations(this::putService, this);
>>>
>>> The called method in turn calls consumer.accept
>>>
>>>              consumer.accept(new Service(provider,
>>> PASSWORD_FACTORY_TYPE, algorithm,
>>> "org.wildfly.security.password.impl.PasswordFactorySpiImpl", emptyList,
>>> emptyMap));
>>>
>>> which enters enters MethodHandleNative::linkDynamicConstant()
>>>
>>> > Debugging shows that the call to linkDynamicConstant() returns null.
>>> >
>>> > A simple reproducer for the problem is available as a maven project on
>>> > github:
>>> >
>>> >    https://github.com/tristantarrant/elytron-leyden
>>> >
>>> > The ReadMe provides an explanation of how to reproduce the problem. I
>>> > did so and the debugged to find out some of the details of what is
>>> > happening (see below) but did not fully clarify the problem. Help from
>>> > someone more conversant with the ins and outs of method handle
>>> > bootstraps in premain would be welcome. Details follow.
>>> >
>>> > regards,
>>> >
>>> >
>>> > Andrew Dinn
>>> > -----------
>>> >
>>> > I downloaded the git repo and attached the Java sources using Maven
>>> command
>>> >
>>> >    $ mvn dependency:sources
>>> >
>>> > Having manifested the crash by following the instructions in the
>>> README
>>> > I reran the leyden JVM under gdb using the following commands to
>>> enable
>>> > Java debugging
>>> >
>>> > $ gdb ${LEYDEN_HOME}/bin/java
>>> > (gdb) cd /path/to/mvn/project
>>> > (gdb) run
>>> > -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
>>> > -classpath
>>> >
>>> /home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/
>>> 2.5.1.Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar
>>> -XX:CacheDataStore=elytron.aot com.redhat.leyden.Main
>>> >
>>> > The problem manifests at WildflyElytronBaseProvider.java:112 in method
>>> > WildflyElytronBaseProvider::putMakedPasswordImplementations
>>>
>>>      static void putMakedPasswordImplementations(Consumer<Service>
>>> consumer, Provider provider) {
>>>          for (String algorithm : MASKED_ALGORITHMS) {
>>>              consumer.accept(new Service(provider,
>>> PASSWORD_FACTORY_TYPE, algorithm,
>>> "org.wildfly.security.password.impl.PasswordFactorySpiImpl", emptyList,
>>> emptyMap)); <== NPE under this call
>>>          }
>>>
>>>
>>> > The source code for this method can be found in the following source
>>> jar
>>> >
>>> >
>>> >
>>> ${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar
>>> >
>>> > (where M2_REPO will normally be ~/.m2/repository)
>>> >
>>> > Stepping into accept eventually enters
>>> MethodHandleNative::linkDynamicConstant
>>> > which in turn enters into ConstantBootstraps.makeConstant(). The
>>> caller
>>> > Class at this point is a lambda class which prints as
>>> > org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c
>>> >
>>> > Several steps further the code enters BootstrapMethodInvoker::invoke
>>> > (below the app method call but via 3 hidden frames) with
>>> bootstrapMethod
>>> > bound to a DirectMethodHandle. After several more steps this enters
>>> > DirectMethodHandle$Holder.invokeStatic which in turn calls
>>> > MethodHandles::classData(Lookup,String,Class).
>>> >
>>> > At this point caller is a MethodHandleLookup for the lambda class
>>> > Lambda/0x800000000c mentioned above. The following call
>>> >
>>> >           Object classdata = classData(caller.lookupClass());
>>> >
>>> > returns null to DirectMethodHandle$Holder.invokeStatic which pops the
>>> > same result back out to BootstrapMethodInvoker::invoke at line 90
>>> >
>>> >                  if (type instanceof Class<?> c) {
>>> >                      result = bootstrapMethod.invoke(caller, name, c);
>>> > <== null
>>> >
>>> > This null result pops back out as the value for the call to
>>> > BootstrapMethodInvoker.invoke(), ConstantBootstraps.makeConstant() and
>>> > MethodHandleNative::linkDynamicConstant().
>>> >
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240913/de8182f4/attachment.htm>

From shade at openjdk.org  Mon Sep 16 05:34:18 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 16 Sep 2024 05:34:18 GMT
Subject: RFR: Reformat internal profiling stats [v2]
In-Reply-To: <C0bEW0lvaGa8zdqAbPNTIwbi_N3BYkGQ9esQukmD3VY=.852a52f7-48f3-4568-86e5-a94194ef3a1a@github.com>
References: <BWF3jak3Q7K_pwiHDphZWkLr8SZAd73JcwKvuPprvYY=.c281cf2b-ffa6-46d3-972a-bf97ed119e33@github.com>
 <C0bEW0lvaGa8zdqAbPNTIwbi_N3BYkGQ9esQukmD3VY=.852a52f7-48f3-4568-86e5-a94194ef3a1a@github.com>
Message-ID: <ury5ixFm9TuIhZQhYp5QKIB5hbwh3OF7WRP2BvsAprA=.d36abe2f-c028-46db-9841-9086e3fe3651@github.com>

On Mon, 9 Sep 2024 17:37:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> For HelloWorld/javac workloads, the current output resolution in milliseconds is not enough, we better off printing microseconds. Plus, indenting is not agreeing in interpreter/C1/C2 outputs, fixed that as well.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace

Thanks!

-------------

PR Comment: https://git.openjdk.org/leyden/pull/18#issuecomment-2352046231

From duke at openjdk.org  Mon Sep 16 05:34:18 2024
From: duke at openjdk.org (duke)
Date: Mon, 16 Sep 2024 05:34:18 GMT
Subject: RFR: Reformat internal profiling stats [v2]
In-Reply-To: <C0bEW0lvaGa8zdqAbPNTIwbi_N3BYkGQ9esQukmD3VY=.852a52f7-48f3-4568-86e5-a94194ef3a1a@github.com>
References: <BWF3jak3Q7K_pwiHDphZWkLr8SZAd73JcwKvuPprvYY=.c281cf2b-ffa6-46d3-972a-bf97ed119e33@github.com>
 <C0bEW0lvaGa8zdqAbPNTIwbi_N3BYkGQ9esQukmD3VY=.852a52f7-48f3-4568-86e5-a94194ef3a1a@github.com>
Message-ID: <lwq9Y_VxD5L5NxuIVxXCIozaNAf81Rtpny40F7xvfbM=.0fe8c584-d772-4f03-b0d6-fe6cc3d02783@github.com>

On Mon, 9 Sep 2024 17:37:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> For HelloWorld/javac workloads, the current output resolution in milliseconds is not enough, we better off printing microseconds. Plus, indenting is not agreeing in interpreter/C1/C2 outputs, fixed that as well.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace

@shipilev 
Your change (at version 3e3124054579cc5e71d900c91120c984d88ed23b) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/18#issuecomment-2352046720

From adinn at openjdk.org  Mon Sep 16 09:16:20 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 16 Sep 2024 09:16:20 GMT
Subject: git: openjdk/leyden: premain: Reformat internal profiling stats
Message-ID: <d058f9e8-c9f6-4506-9735-a5712ea82d4b@openjdk.org>

Changeset: a8b8d7da
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: Andrew Dinn <adinn at openjdk.org>
Date:      2024-09-16 09:13:44 +0000
URL:       https://git.openjdk.org/leyden/commit/a8b8d7da9ecbdfedbf30ec430aaa1deea9343962

Reformat internal profiling stats

Reviewed-by: kvn

! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp
! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/opto/runtime.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/methodHandles.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/perfData.hpp
! src/hotspot/share/runtime/perfData.inline.hpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/vmThread.cpp
! src/hotspot/share/services/management.cpp
! src/hotspot/share/services/management.hpp


From shade at openjdk.org  Mon Sep 16 09:16:25 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 16 Sep 2024 09:16:25 GMT
Subject: Integrated: Reformat internal profiling stats
In-Reply-To: <BWF3jak3Q7K_pwiHDphZWkLr8SZAd73JcwKvuPprvYY=.c281cf2b-ffa6-46d3-972a-bf97ed119e33@github.com>
References: <BWF3jak3Q7K_pwiHDphZWkLr8SZAd73JcwKvuPprvYY=.c281cf2b-ffa6-46d3-972a-bf97ed119e33@github.com>
Message-ID: <9esrGRjKkzd5cyZmgQ4fJWf1SgG-SWXqEhIfrHZfzWo=.b4acbca1-3f93-45e2-bc8b-39a2cc13b78b@github.com>

On Mon, 9 Sep 2024 11:05:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> For HelloWorld/javac workloads, the current output resolution in milliseconds is not enough, we better off printing microseconds. Plus, indenting is not agreeing in interpreter/C1/C2 outputs, fixed that as well.

This pull request has now been integrated.

Changeset: a8b8d7da
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: Andrew Dinn <adinn at openjdk.org>
URL:       https://git.openjdk.org/leyden/commit/a8b8d7da9ecbdfedbf30ec430aaa1deea9343962
Stats:     80 lines in 15 files changed: 17 ins; 0 del; 63 mod

Reformat internal profiling stats

Reviewed-by: kvn

-------------

PR: https://git.openjdk.org/leyden/pull/18

From shade at openjdk.org  Mon Sep 16 10:43:46 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 16 Sep 2024 10:43:46 GMT
Subject: RFR: Enable 1-step workflow with Shenandoah GC [v2]
In-Reply-To: <o-jjFUp6XKu9fFF9_BDQ6Gf2xi4I4I5cUJlvq_evKrY=.8419a68c-ae5f-43f0-b332-1d421472d9c7@github.com>
References: <o-jjFUp6XKu9fFF9_BDQ6Gf2xi4I4I5cUJlvq_evKrY=.8419a68c-ae5f-43f0-b332-1d421472d9c7@github.com>
Message-ID: <C3J3vIlmdWLI35zYjtsWtcxNH699hQlYx64boDecdkI=.2f109a59-99a9-48c4-bd6f-a4d2c345c200@github.com>

> WIP, includes upstream [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650).
> 
> I checked this works well:
> 
> 
> #!/bin/bash
> make images
> J=build/macosx-aarch64-server-fastdebug/images/jdk/bin/java
> rm -fv JavacBenchApp.cds*
> $J -XX:+UseShenandoahGC -XX:CacheDataStore=JavacBenchApp.cds -cp JavacBenchApp.jar JavacBenchApp 50
> $J -XX:+UseShenandoahGC -XX:CacheDataStore=JavacBenchApp.cds -cp JavacBenchApp.jar JavacBenchApp 50
> 
> 
> I'll look around what other tests I need to run.

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Missing clone_barrier in SC table
 - Temporary drop the alignment, so that tests work
 - Shenandoah support

-------------

Changes: https://git.openjdk.org/leyden/pull/8/files
  Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=8&range=01
  Stats: 49 lines in 7 files changed: 34 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/leyden/pull/8.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/8/head:pull/8

PR: https://git.openjdk.org/leyden/pull/8

From asmehra at openjdk.org  Mon Sep 16 16:32:36 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Mon, 16 Sep 2024 16:32:36 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v3]
In-Reply-To: <sGbZxClkC1gVEtSjILXVTarW-ns_8Vv3Ylgbgq7rLqY=.29b21ee8-da43-44d8-b882-e194f4a79cb3@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
 <sGbZxClkC1gVEtSjILXVTarW-ns_8Vv3Ylgbgq7rLqY=.29b21ee8-da43-44d8-b882-e194f4a79cb3@github.com>
Message-ID: <19LUYVnFDk2Dz1jfUJe1_ZBklAnHxDgfEyPMuU5c8As=.99d9b83d-cfca-4e66-9090-9caa0a677f3e@github.com>

On Wed, 11 Sep 2024 22:24:53 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> AOT training can be ended using either
>> 
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
>> - jcmd <pid> AOT.end_training
>> 
>> supports arm64 and x64
>> 
>> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
>> 
>> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   another missing include that impacts some build configurations

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1403:

> 1401: 
> 1402: void InterpreterMacroAssembler::end_training_check() {
> 1403:   if (!FLAG_IS_DEFAULT(AOTEndTrainingOnMethodEntry) && CDSPreimage == nullptr) {

CDSPreimage == nullptr may not be enough as it is would be null when AOTCache is not used at all. There is an API in CDSConfig that can be used here to check for training run: CDSConfig::is_dumping_preimage_static_archive().
Also, I think it would be cleaner if these checks can be encapsulated in an API in CDSConfig.

src/hotspot/share/code/nmethod.hpp line 521:

> 519:   bool is_java_method         () const { return _method != nullptr && !_method->is_native(); }
> 520:   bool is_osr_method          () const { return _entry_bci != InvocationEntryBci; }
> 521:   bool is_end_training_trigger() const { return _method != nullptr && _method->is_end_training_trigger(); }

Is this used anywhere?

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1761472382
PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1761472599

From asmehra at openjdk.org  Mon Sep 16 16:36:26 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Mon, 16 Sep 2024 16:36:26 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v3]
In-Reply-To: <sGbZxClkC1gVEtSjILXVTarW-ns_8Vv3Ylgbgq7rLqY=.29b21ee8-da43-44d8-b882-e194f4a79cb3@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
 <sGbZxClkC1gVEtSjILXVTarW-ns_8Vv3Ylgbgq7rLqY=.29b21ee8-da43-44d8-b882-e194f4a79cb3@github.com>
Message-ID: <x62jsgOjfACl7pQcCmGqbQH9fk2bOImxU4vgkFajyqA=.7e14ff0d-f5db-430b-b946-99743fe3914b@github.com>

On Wed, 11 Sep 2024 22:24:53 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> AOT training can be ended using either
>> 
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
>> - jcmd <pid> AOT.end_training
>> 
>> supports arm64 and x64
>> 
>> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
>> 
>> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   another missing include that impacts some build configurations

@macarte  Can we specify multiple methods each with its own value for `count` as triggers?

src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1276:

> 1274: 
> 1275:   // AOT training run support
> 1276:   __ end_training_check();

Does it make sense to do these checks after `notify_method_entry()`? It could aid in debugging/testing that the training run indeed ended on this method entry.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/21#issuecomment-2353397733
PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1761477104

From asmehra at openjdk.org  Mon Sep 16 16:42:39 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Mon, 16 Sep 2024 16:42:39 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v3]
In-Reply-To: <sGbZxClkC1gVEtSjILXVTarW-ns_8Vv3Ylgbgq7rLqY=.29b21ee8-da43-44d8-b882-e194f4a79cb3@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
 <sGbZxClkC1gVEtSjILXVTarW-ns_8Vv3Ylgbgq7rLqY=.29b21ee8-da43-44d8-b882-e194f4a79cb3@github.com>
Message-ID: <-CLCqdggH1GaiDChT65Gak7At0eB8bDlKlSzUs5CMAc=.3b3fa29e-2c00-44ca-87a9-4f324721e220@github.com>

On Wed, 11 Sep 2024 22:24:53 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> AOT training can be ended using either
>> 
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
>> - jcmd <pid> AOT.end_training
>> 
>> supports arm64 and x64
>> 
>> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
>> 
>> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   another missing include that impacts some build configurations

Minor suggestions

-------------

PR Review: https://git.openjdk.org/leyden/pull/21#pullrequestreview-2307169957

From macarte at openjdk.org  Mon Sep 16 21:36:19 2024
From: macarte at openjdk.org (Mat Carter)
Date: Mon, 16 Sep 2024 21:36:19 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v3]
In-Reply-To: <19LUYVnFDk2Dz1jfUJe1_ZBklAnHxDgfEyPMuU5c8As=.99d9b83d-cfca-4e66-9090-9caa0a677f3e@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
 <sGbZxClkC1gVEtSjILXVTarW-ns_8Vv3Ylgbgq7rLqY=.29b21ee8-da43-44d8-b882-e194f4a79cb3@github.com>
 <19LUYVnFDk2Dz1jfUJe1_ZBklAnHxDgfEyPMuU5c8As=.99d9b83d-cfca-4e66-9090-9caa0a677f3e@github.com>
Message-ID: <94K8q-8YmwvEwHsKg9gUnm1Ur36Lzm3E0-1l1QeyxZ8=.a26fd2ff-b19a-49c2-8a51-c8d0b5652758@github.com>

On Mon, 16 Sep 2024 16:30:14 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another missing include that impacts some build configurations
>
> src/hotspot/share/code/nmethod.hpp line 521:
> 
>> 519:   bool is_java_method         () const { return _method != nullptr && !_method->is_native(); }
>> 520:   bool is_osr_method          () const { return _entry_bci != InvocationEntryBci; }
>> 521:   bool is_end_training_trigger() const { return _method != nullptr && _method->is_end_training_trigger(); }
> 
> Is this used anywhere?

not anymore, will remove

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1761991727

From macarte at openjdk.org  Mon Sep 16 21:40:21 2024
From: macarte at openjdk.org (Mat Carter)
Date: Mon, 16 Sep 2024 21:40:21 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v3]
In-Reply-To: <19LUYVnFDk2Dz1jfUJe1_ZBklAnHxDgfEyPMuU5c8As=.99d9b83d-cfca-4e66-9090-9caa0a677f3e@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
 <sGbZxClkC1gVEtSjILXVTarW-ns_8Vv3Ylgbgq7rLqY=.29b21ee8-da43-44d8-b882-e194f4a79cb3@github.com>
 <19LUYVnFDk2Dz1jfUJe1_ZBklAnHxDgfEyPMuU5c8As=.99d9b83d-cfca-4e66-9090-9caa0a677f3e@github.com>
Message-ID: <T9ytB19tM-b1a1w1z4lxk1hmBXuj5lQdw3_yVafLk8o=.118e4856-441b-4c26-87c9-46bb4ee75bc0@github.com>

On Mon, 16 Sep 2024 16:30:04 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another missing include that impacts some build configurations
>
> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1403:
> 
>> 1401: 
>> 1402: void InterpreterMacroAssembler::end_training_check() {
>> 1403:   if (!FLAG_IS_DEFAULT(AOTEndTrainingOnMethodEntry) && CDSPreimage == nullptr) {
> 
> CDSPreimage == nullptr may not be enough as it is would be null when AOTCache is not used at all. There is an API in CDSConfig that can be used here to check for training run: CDSConfig::is_dumping_preimage_static_archive().
> Also, I think it would be cleaner if these checks can be encapsulated in an API in CDSConfig.

added a simple is_dumping_preimage_static_archive_with_triggers

> src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1276:
> 
>> 1274: 
>> 1275:   // AOT training run support
>> 1276:   __ end_training_check();
> 
> Does it make sense to do these checks after `notify_method_entry()`? It could aid in debugging/testing that the training run indeed ended on this method entry.

good call, will swap order of notify_method_entry and end_training_check

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1761995190
PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1761994473

From macarte at openjdk.org  Mon Sep 16 21:43:20 2024
From: macarte at openjdk.org (Mat Carter)
Date: Mon, 16 Sep 2024 21:43:20 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v3]
In-Reply-To: <x62jsgOjfACl7pQcCmGqbQH9fk2bOImxU4vgkFajyqA=.7e14ff0d-f5db-430b-b946-99743fe3914b@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
 <sGbZxClkC1gVEtSjILXVTarW-ns_8Vv3Ylgbgq7rLqY=.29b21ee8-da43-44d8-b882-e194f4a79cb3@github.com>
 <x62jsgOjfACl7pQcCmGqbQH9fk2bOImxU4vgkFajyqA=.7e14ff0d-f5db-430b-b946-99743fe3914b@github.com>
Message-ID: <Xc7A-8ifRKXiLn9Dz9XHIZetVmLc1rpU4QUfJHr2Ub0=.65502abb-13c7-4365-9674-5dd85089076c@github.com>

On Mon, 16 Sep 2024 16:34:10 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> @macarte Can we specify multiple methods each with its own value for `count` as triggers?

We decided to keep it simple for now; to support separate counts would require a map of methods to counts and using wildcards its possible to have many triggers e.g. java/lang/string.*.  Also while the compilers only add trigger_checks to the specified methods, due to the interpreter using a common method entry even a hash lookup would likely degrade the performance with so many calls

-------------

PR Comment: https://git.openjdk.org/leyden/pull/21#issuecomment-2354076442

From macarte at openjdk.org  Mon Sep 16 21:53:32 2024
From: macarte at openjdk.org (Mat Carter)
Date: Mon, 16 Sep 2024 21:53:32 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v4]
In-Reply-To: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
Message-ID: <N6UHbddQMxcwh_HunT6ozzTWBT8V73UhZV6sUxzw_yU=.8a7716aa-90ff-4734-9184-40b95e328b39@github.com>

> AOT training can be ended using either
> 
> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
> - jcmd <pid> AOT.end_training
> 
> supports arm64 and x64
> 
> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
> 
> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358

Mat Carter has updated the pull request incrementally with two additional commits since the last revision:

 - Removed include no longer needed
 - Calling preimage dump directly so execution can continue (also addressed PR feedback)

-------------

Changes:
  - all: https://git.openjdk.org/leyden/pull/21/files
  - new: https://git.openjdk.org/leyden/pull/21/files/b3098cfc..4244849a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=03
 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=02-03

  Stats: 118 lines in 15 files changed: 52 ins; 57 del; 9 mod
  Patch: https://git.openjdk.org/leyden/pull/21.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/21/head:pull/21

PR: https://git.openjdk.org/leyden/pull/21

From macarte at openjdk.org  Mon Sep 16 22:18:30 2024
From: macarte at openjdk.org (Mat Carter)
Date: Mon, 16 Sep 2024 22:18:30 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v5]
In-Reply-To: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
Message-ID: <O62aA2NFpuIOziFFeYmSzfkY7ZkI3n127LHUK3ZyYlI=.822b9602-be51-4c78-b36d-8a4747d452f0@github.com>

> AOT training can be ended using either
> 
> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
> - jcmd <pid> AOT.end_training
> 
> supports arm64 and x64
> 
> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
> 
> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  removed extra space left over from reverted change

-------------

Changes:
  - all: https://git.openjdk.org/leyden/pull/21/files
  - new: https://git.openjdk.org/leyden/pull/21/files/4244849a..5241ca39

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=04
 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=03-04

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/leyden/pull/21.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/21/head:pull/21

PR: https://git.openjdk.org/leyden/pull/21

From jrose at openjdk.org  Tue Sep 17 02:32:48 2024
From: jrose at openjdk.org (John R Rose)
Date: Tue, 17 Sep 2024 02:32:48 GMT
Subject: RFR: Add Premain EA link, Premain JEP links, link to training run doc
Message-ID: <-QyLFel9ZXkWpKPXYtPkHnH0hT43XnSi9shFLcpRqi8=.7dcd0b5e-e2b4-471f-abf3-94e98618ca65@github.com>

Some adds to the index page:

 - premain JEP and EA links
 - link to Dan's doc about training runs

One thing that baffled me a bit is the `<br/>` elements in the markdown.  These seem to be either hand-inserted as an attempt to do line length control, or else they are artifacts of an old cut-and-paste. Do we really want them?  If so, can we put in a comment in the markdown that says how to maintain them, please?

-------------

Commit messages:
 - Add Premain EA link, Premain JEP links, link to training run doc

Changes: https://git.openjdk.org/leyden-docs/pull/4/files
  Webrev: https://webrevs.openjdk.org/?repo=leyden-docs&pr=4&range=00
  Stats: 7 lines in 1 file changed: 6 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/leyden-docs/pull/4.diff
  Fetch: git fetch https://git.openjdk.org/leyden-docs.git pull/4/head:pull/4

PR: https://git.openjdk.org/leyden-docs/pull/4

From iklam at openjdk.org  Tue Sep 17 04:11:20 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 17 Sep 2024 04:11:20 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v5]
In-Reply-To: <O62aA2NFpuIOziFFeYmSzfkY7ZkI3n127LHUK3ZyYlI=.822b9602-be51-4c78-b36d-8a4747d452f0@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
 <O62aA2NFpuIOziFFeYmSzfkY7ZkI3n127LHUK3ZyYlI=.822b9602-be51-4c78-b36d-8a4747d452f0@github.com>
Message-ID: <8xP9tNV6fXa3r3AgqZwytZJZcqiRm1ebolu7TW3I790=.dddc1c09-d14d-4e13-9125-c72c30f3b395@github.com>

On Mon, 16 Sep 2024 22:18:30 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> AOT training can be ended using either
>> 
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
>> - jcmd <pid> AOT.end_training
>> 
>> supports arm64 and x64
>> 
>> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
>> 
>> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed extra space left over from reverted change

I would suggest adding some sanity test cases. You can make a copy of test/hotspot/jtreg/runtime/cds/appcds/leyden/LeydenHello.java and rename the classes accordingly. Then, add the following to the `Tester` inner class:


        @Override
        public String[] vmArgs(RunMode runMode) {
            return new String[] {
                 "-XX: AOTEndTrainingOnMethodEntry=??????",
            };
        }


For jcmd, you can make a copy of test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestStaticDump.java, strip most of it and leave only one copy of this:


        app  = createLingeredApp("-XX:CacheDataStore=foo.cds", "-cp", allJars);
        pid = app.getPid();
        test("foo.cds", pid, .....);
        app.stopApp();


You also need to modify JCmdTestDumpBase.java so it can dispatch the "AOT.end_training" command instead.

> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified

I think this is OK. Filtering out the option from the command-line is non trivial; ignoring it is much simpler.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/21#issuecomment-2354464924

From iklam at openjdk.org  Tue Sep 17 04:41:24 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 17 Sep 2024 04:41:24 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v5]
In-Reply-To: <O62aA2NFpuIOziFFeYmSzfkY7ZkI3n127LHUK3ZyYlI=.822b9602-be51-4c78-b36d-8a4747d452f0@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
 <O62aA2NFpuIOziFFeYmSzfkY7ZkI3n127LHUK3ZyYlI=.822b9602-be51-4c78-b36d-8a4747d452f0@github.com>
Message-ID: <o5nLJ9rBREcqmjM_6CuPLqt_laP0lgq3lHXMfq3KQK8=.417ac24d-a36d-405e-8b16-a73315bd2bb6@github.com>

On Mon, 16 Sep 2024 22:18:30 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> AOT training can be ended using either
>> 
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
>> - jcmd <pid> AOT.end_training
>> 
>> supports arm64 and x64
>> 
>> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
>> 
>> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed extra space left over from reverted change

src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1280:

> 1278:   // AOT training run support
> 1279:   __ end_training_check();
> 1280: 

I wonder how much this will slow down the interpreter, as we trap into the VM on every interpreter entry. Could you do something like


long start = System.currentTimeMillis();
for (int i = 0; i < 10000000; i++) {
    emptyMethod();
}
System.out.println(System.currentMillis() - start();


and run it with something like this? 


rm foo.cds
java -Xint  -XX:+UnlockDiagnosticVMOptions -XX:+CDSManualFinalImage -XX:CacheDataStore=foo.cds ...

src/hotspot/share/opto/parse1.cpp line 1215:

> 1213:   }
> 1214: 
> 1215:   if (CDSConfig::is_dumping_preimage_static_archive_with_triggers() && method()->is_end_training_trigger()) {

Do we come here also if `method()` is being inlined by C2?

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1762265518
PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1762269791

From iklam at openjdk.org  Tue Sep 17 04:41:24 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 17 Sep 2024 04:41:24 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v3]
In-Reply-To: <XGXLVDzhpqxG3ouwhFzchZTczFykwJvyIeBcMkkjCxI=.8e31f6dc-d961-4a05-a88e-230898b0563f@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
 <sGbZxClkC1gVEtSjILXVTarW-ns_8Vv3Ylgbgq7rLqY=.29b21ee8-da43-44d8-b882-e194f4a79cb3@github.com>
 <XGXLVDzhpqxG3ouwhFzchZTczFykwJvyIeBcMkkjCxI=.8e31f6dc-d961-4a05-a88e-230898b0563f@github.com>
Message-ID: <dqgWT3miGenFyfa8GJFNrhet5_eON-OhTkmDsKwCB14=.d556d5be-3074-4c4b-ac42-13f38c86b876@github.com>

On Thu, 12 Sep 2024 17:35:36 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another missing include that impacts some build configurations
>
> src/hotspot/share/services/diagnosticCommand.hpp line 410:
> 
>> 408:     static const JavaPermission permission() {
>> 409:     JavaPermission p = {"java.lang.management.ManagementPermission",
>> 410:                         "monitor", nullptr};
> 
> Should this be 'monitor' or 'control' (or something else)?

I think "monitor" is appropriate (used also for dumping heap, etc). The API says "control" is to "control the runtime characteristics of the Java virtual machine", but we aren't really modifying the runtime characteristics.

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1762272495

From iklam at openjdk.org  Tue Sep 17 04:43:21 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 17 Sep 2024 04:43:21 GMT
Subject: RFR: Enable 1-step workflow with Shenandoah GC [v2]
In-Reply-To: <C3J3vIlmdWLI35zYjtsWtcxNH699hQlYx64boDecdkI=.2f109a59-99a9-48c4-bd6f-a4d2c345c200@github.com>
References: <o-jjFUp6XKu9fFF9_BDQ6Gf2xi4I4I5cUJlvq_evKrY=.8419a68c-ae5f-43f0-b332-1d421472d9c7@github.com>
 <C3J3vIlmdWLI35zYjtsWtcxNH699hQlYx64boDecdkI=.2f109a59-99a9-48c4-bd6f-a4d2c345c200@github.com>
Message-ID: <SGLMTWwpvXNWhJDkyMgXoIRQ7gMmYj5FdA9FWE537PE=.ec8d89be-1bca-4ca4-abbf-3e5875a0ec5d@github.com>

On Mon, 16 Sep 2024 10:43:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> WIP, includes upstream [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650).
>> 
>> I checked this works well:
>> 
>> 
>> #!/bin/bash
>> make images
>> J=build/macosx-aarch64-server-fastdebug/images/jdk/bin/java
>> rm -fv JavacBenchApp.cds*
>> $J -XX:+UseShenandoahGC -XX:CacheDataStore=JavacBenchApp.cds -cp JavacBenchApp.jar JavacBenchApp 50
>> $J -XX:+UseShenandoahGC -XX:CacheDataStore=JavacBenchApp.cds -cp JavacBenchApp.jar JavacBenchApp 50
>> 
>> 
>> I'll look around what other tests I need to run.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Missing clone_barrier in SC table
>  - Temporary drop the alignment, so that tests work
>  - Shenandoah support

LGTM

-------------

Marked as reviewed by iklam (Committer).

PR Review: https://git.openjdk.org/leyden/pull/8#pullrequestreview-2308239015

From ioi.lam at oracle.com  Tue Sep 17 05:10:46 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Mon, 16 Sep 2024 22:10:46 -0700
Subject: premain: Crash in Infinispan server code caused by NPE under
 MethodHandleNative::linkDynamicConstant
In-Reply-To: <CAKt0pyT48uPH6rUL7bEJ2rtWqNdNL34DWBJ2SDaHwYfVxURnQw@mail.gmail.com>
References: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
 <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>
 <CAKt0pySztvwsadtrqjai6XwakAWq_v_o8men4aopLo4X-0azyQ@mail.gmail.com>
 <CAKt0pyQ44E+npyUW35Zhxg+PfBgF2yuNgS61gj1GGj=aLGTJXw@mail.gmail.com>
 <CAKt0pyT48uPH6rUL7bEJ2rtWqNdNL34DWBJ2SDaHwYfVxURnQw@mail.gmail.com>
Message-ID: <0d22d580-39a1-4105-a50e-8a74a555090d@oracle.com>

Hi Ashutosh,

So this looks like a potential bug (or feature) in the core lib code. 
When CDS forcefully initializes a class in an unexpected (or untested) 
order, the "initialization soup" fails.

Perhaps a work-around would be to make some harmless calls at the place 
where CDS was calling into MethodType.createArchivedObjects(). E.g., do 
something like this:

+??? if (CDSConfig::is_dumping_invokedynamic()) {
+?????? // call into Java: jdk.internal.misc::warmupInvokeDynamic();
+?? }
 ??? // Rewrite and link classes
 ??? log_info(cds)("Rewriting and linking classes ...");

Maybe you can add a new Lambda expressions, MethodHandle invocations, 
etc, that would hopefully cause PrimitiveClassDescImpl and friends to be 
initialized in their natural order.

Or call class.forName("java.lang.constant.ConstantDescs") ??

BTW, you can see my comments in 
AOTClassInitializer::is_forced_preinit_class():

 ??? // TODO:
 ??? // This is needed since JDK-8338532. Without this, when
 ??? // archived heap objects are used, the class init order is not
 ??? // expected by the jdk/internal/constant bootstrap code and we
 ??? // will get a null pointer exception.
 ??? //
 ??? // When bootstraping has intricated/fragile order, it's probably
 ??? // better to archive all related classes in an initialized state
 ??? // (i.e., take a snapshot). The existing approach in
 ??? // heapShared::resolve_or_init_classes_for_subgraph_of() won't work.
 ??? "jdk/internal/constant/PrimitiveClassDescImpl",
 ??? "jdk/internal/constant/ReferenceClassDescImpl",
 ??? "java/lang/constant/ConstantDescs",
 ??? "sun/invoke/util/Wrapper",

I was having a similar circularity issue (but in production time) and I 
just added enough classes to make the NPE go away. For your test case, 
if you manage to fix in in the assembly run but run into NPE in 
production run, you might need to add more classes to this list. Yes, 
it's a hack :-(


Thanks

- Ioi

On 9/13/24 7:05 PM, Ashutosh Mehra wrote:
> This is turning out to be a real example of class initialization soup!
> As mentioned during the meeting, I am getting NPE in the assembly 
> phase when testing the patch [0] that I proposed in my earlier mail
> using a test case inspired by the Infinispan code.
> NPE occurs when running the class initializer for PrimitiveClassDescImpl
> Interestingly, PrimitiveClassDescImpl?is "forcefully" initialized by 
> MetaspaceShared::link_shared_classes().
>
> I couldn't get a stack trace so I relied on exception logs (using 
> -Xlog:exceptions=trace) to find the cause which indicate following 
> frames on the stack:
>
> [0] 
> jdk/internal/constant/MethodTypeDescImpl::validateArgument(Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/ClassDesc;?@ 
> bci 1
> [1] 
> jdk/internal/constant/MethodTypeDescImpl::ofTrusted(Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljdk/internal/constant/MethodTypeDescImpl;?@ 
> bci 27
> [2] 
> java/lang/constant/ConstantDescs::ofConstantBootstrap(Ljava/lang/constant/ClassDesc;Ljava/lang/String;Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/DirectMethodHandleDesc;?@ 
> bci 47
> [3] java/lang/constant/ConstantDescs::<clinit>?@ bci 664
> [4] 
> jdk/internal/constant/PrimitiveClassDescImpl::<init>(Ljava/lang/String;)V?@ 
> bci 1
> [5] 
> jdk/internal/constant/PrimitiveClassDescImpl::<clinit>(Ljava/lang/String;)V?@ 
> bci 6
>
> Notice?that invocation of PrimitiveClassDescImpl::<clinit> results in 
> initialization of ConstantDescs?class (see frame 3).
> ConstantDescs::<clinit>?@ 664 corresponds to following java code:
>
> ? ? public static final DirectMethodHandleDesc BSM_CLASS_DATA_AT
> ? ? ? ? ? ? = ofConstantBootstrap(CD_MethodHandles, "classDataAt",
> ? ? ? ? ? ? CD_Object, CD_int);
>
> The last parameter CD_int is initialized as:
>
> ? ? public static final ClassDesc CD_int = PrimitiveClassDescImpl.CD_int;
>
> So, its value is obtained from PrimitiveClassDescImpl.CD_int?which 
> hasn't been initialized properly yet. As a result 
> ConstantDescs::CD_int is assigned?null which results in 
> MethodTypeDescImpl::validateArgument throwing NPE later.
> There is a clear class initialization circularity involving 
> PrimitiveClassDescImpl and ConstantDescs, and the result depends on 
> which class gets initialized first.
>
> Without my patch this issue is not seen because PrimitiveClassDescImpl 
> has already been initialized by the time 
> MetaspaceShared::link_shared_classes()?is called.
> Its initialization is triggered by the call to 
> MethodType::createArchivedObjects().
> It also explains why my patch introduced this issue because it 
> effectively moved the call to MethodType::createArchivedObjects() 
> after MetaspaceShared::link_shared_classes().
>
> [0] 
> https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e 
> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>
> Thanks,
> - Ashutosh Mehra
>
>
> On Wed, Sep 11, 2024 at 3:12?PM Ashutosh Mehra <asmehra at redhat.com> wrote:
>
>     Regarding the WrongMethodTypeException that I mentioned in my
>     previous email (see pt 3),
>     this exception happens when lambda proxy class attempts to invoke
>     the MethodHandle it obtained from the classData:
>
>     ? public void accept(java.lang.Object);
>     ? ? descriptor: (Ljava/lang/Object;)V
>     ? ? flags: (0x0001) ACC_PUBLIC
>     ? ? Code:
>     ? ? ? stack=3, locals=2, args_size=2
>     ? ? ? ? ?0: ldc ? ? ? ? ? #26 ? ? ? ? ? ? ? ? // Dynamic
>     #0:_:Ljava/lang/invoke/MethodHandle;
>     ? ? ? ? ?2: aload_0
>     ? ? ? ? ?3: getfield ? ? ?#13 ? ? ? ? ? ? ? ? // Field
>     arg$1:Lorg/wildfly/security/WildFlyElytronBaseProvider;
>     ? ? ? ? ?6: aload_1
>     ? ? ? ? ?7: checkcast ? ? #28 ? ? ? ? ? ? ? ? // class
>     java/security/Provider$Service
>     ? ? ? ? 10: invokevirtual #34 ? ? ? ? ? ? ? ? // Method
>     java/lang/invoke/MethodHandle.invokeExact:(Lorg/wildfly/security/WildFlyElytronBaseProvider;Ljava/security/Provider$Service;)V
>     ? ? ? ? 13: return
>
>     The scenario is during the assembly phase as part of the indy
>     resolution the MethodHandle for which the exception is thrown gets
>     created.
>     Normally MethodHandle's type gets added in MethodType::internTable
>     but by the time indy resolution happens, JVM has already taken
>     snapshot of the MethodType::internTable through an upcall to
>     MethodType::createArchivedObjects().
>     As a result the AOTCache ends up with the MethodType object which
>     is not in AOTHolder.archivedMethodTypes.
>
>     During the production run, when the jvm invokes the MethodHandle,
>     it searches for the MethodType corresponding to the signature
>     passed at the callsite.
>     As expected, it fails to find it in the
>     AOTHolder.archivedMethodTypes, so it creates a new instance of the
>     MethodType.
>     But Invokers.checkExactType() relies on the MethodHandle's?type to
>     be the same object as the MethodType object passed as parameter.
>
>     ? ? static void checkExactType(MethodHandle mhM, MethodType
>     expected) {
>     ? ? ? ? MethodType targetType = mh.type();
>     ? ? ? ? if (targetType != expected)
>     ? ? ? ? ? ? throw newWrongMethodTypeException(targetType, expected);
>     ? ? }
>
>     Hence, it throws WrongMethodTypeException?though the two MT
>     objects have the same signature.
>
>     To handle this scenario, I changed the order of indy resolution
>     and upcall to MethodType::createArchivedObjects()?as:
>
>     diff --git a/src/hotspot/share/cds/metaspaceShared.cpp
>     b/src/hotspot/share/cds/metaspaceShared.cpp
>     index df4bcadefa3..457716cac5b 100644
>     --- a/src/hotspot/share/cds/metaspaceShared.cpp
>     +++ b/src/hotspot/share/cds/metaspaceShared.cpp
>     @@ -751,6 +751,20 @@ void
>     MetaspaceShared::link_shared_classes(bool jcmd_request, TRAPS) {
>     ? ?if (CDSConfig::is_dumping_final_static_archive()) {
>     ? ? ?FinalImageRecipes::apply_recipes(CHECK);
>     ? ?}
>     +
>     +#if INCLUDE_CDS_JAVA_HEAP
>     + ?if (CDSConfig::is_dumping_invokedynamic()) {
>     + ? ?// This makes sure that the MethodType and MethodTypeForm
>     tables won't be updated
>     + ? ?// concurrently when we are saving their contents into a side
>     table.
>     + ?assert(CDSConfig::allow_only_single_java_thread(), "Required");
>     +
>     + ? ?JavaValue result(T_VOID);
>     + ? ?JavaCalls::call_static(&result, vmClasses::MethodType_klass(),
>     + vmSymbols::createArchivedObjects(),
>     + vmSymbols::void_method_signature(),
>     + ? ? ? ? ? ? ? ? ? ? ? ? ? CHECK);
>     + ?}
>     +#endif
>     ?}
>     Note that indy resolution happens as part of
>     FinalImageRecipes::apply_recipes(CHECK) which is now invoked
>     before the upcall to createArchivedObjects().
>     With this change I am able to run the application without any
>     exceptions.
>     My complete patch can be seen here:
>     https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>     <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>     I will do more testing with this patch.
>
>     @Ioi Lam <mailto:ioi.lam at oracle.com>?do you have any feedback on
>     this patch.
>
>     Thanks,
>     - Ashutosh Mehra
>
>
>
>     On Wed, Sep 11, 2024 at 10:14?AM Ashutosh Mehra
>     <asmehra at redhat.com> wrote:
>
>         Hi Andrew,
>         Thanks for sharing the initial investigation.
>         I have been looking into this and have a few of things to add
>         to your analysis:
>
>         1.? As you mentioned the classData for the lambda
>         class?WildFlyElytronBaseProvider$$Lambda is null.
>         The classData is stored in the mirror object of the
>         InstanceKlass when the class is defined
>         through?JVM_LookupDefineClass.
>         However, when we create the scratch mirror object (which get
>         stored in the AOT cache) the classData is not populated.
>         See
>         https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp#L1128-L1131
>         <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp*L1128-L1131__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhbKjzG3gw$>
>
>         ? Handle classData; // set to null. Will be reinitialized at
>         runtime
>         ? Handle mirror;
>         ? Handle comp_mirror;
>         ? allocate_mirror(k, /*is_scratch=*/true, protection_domain,
>         classData, mirror, comp_mirror, CHECK);
>
>         So this explains why the call to
>         classData(caller.lookupClass())returned null.
>
>         2. In the mainline there is a check
>         in?InnerClassLambdaMetafactory.java for the particular code
>         pattern used by the application.
>         If this code pattern is found then the lambda proxy class is
>         not included in the CDS archive.
>         See
>         https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L163-L170
>         <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L163-L170__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZl2S9tQg$>
>         and
>         https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L246
>         <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L246__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhYsI3Xx0g$>
>
>         ? ? ? ? // If the target class invokes a protected method
>         inherited from a
>         ? ? ? ? // superclass in a different package, or does
>         'invokespecial', the
>         ? ? ? ? // lambda class has no access to the resolved method,
>         or does
>         ? ? ? ? // 'invokestatic' on a hidden class which cannot be
>         resolved by name.
>         ? ? ? ? // Instead, we need to pass the live implementation
>         method handle to
>         ? ? ? ? // the proxy class to invoke directly. (javac prefers
>         to avoid this
>         ? ? ? ? // situation by generating bridges in the target class)
>         ? ? ? ? useImplMethodHandle =
>         (Modifier.isProtected(implInfo.getModifiers()) &&
>         ?!VerifyAccess.isSamePackage(targetClass,
>         implInfo.getDeclaringClass())) ||
>         ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?implKind ==
>         MethodHandleInfo.REF_invokeSpecial ||
>         ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?implKind ==
>         MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>
>         In premain lambda proxy classes get included in the AOT cache
>         as a result of indy resolution and that mechanism doesn't have
>         this kind of check.
>
>         3. For the null classData problem mentioned above, I tried to
>         fix it by storing classData in the scratch mirror using the
>         following patch:
>
>         diff --git a/src/hotspot/share/classfile/javaClasses.cpp
>         b/src/hotspot/share/classfile/javaClasses.cpp
>         index bd8141adbcc..41766e98093 100644
>         --- a/src/hotspot/share/classfile/javaClasses.cpp
>         +++ b/src/hotspot/share/classfile/javaClasses.cpp
>         @@ -1094,9 +1094,9 @@ void
>         java_lang_Class::create_mirror(Klass* k, Handle class_loader,
>         ? ? ?}
>         ? ? ?if (CDSConfig::is_dumping_heap()) {
>         ? ? ? ?if (CDSConfig::is_dumping_protection_domains()) {
>         - ? ? ? ?create_scratch_mirror(k, protection_domain, CHECK);
>         + ? ? ? ?create_scratch_mirror(k, protection_domain,
>         classData, CHECK);
>         ? ? ? ?} else {
>         - ? ? ? ?create_scratch_mirror(k, Handle() /* null
>         protection_domain*/, CHECK);
>         + ? ? ? ?create_scratch_mirror(k, Handle() /* null
>         protection_domain*/, classData, CHECK);
>         ? ? ? ?}
>         ? ? ?}
>         ? ?} else {
>         @@ -1117,7 +1117,7 @@ void
>         java_lang_Class::create_mirror(Klass* k, Handle class_loader,
>         ?// Note: we archive the "scratch mirror" instead of
>         k->java_mirror(), because the
>         ?// latter may contain dumptime-specific information that
>         cannot be archived
>         ?// (e.g., ClassLoaderData*, or static fields that are
>         modified by Java code execution).
>         -void java_lang_Class::create_scratch_mirror(Klass* k, Handle
>         protection_domain, TRAPS) {
>         +void java_lang_Class::create_scratch_mirror(Klass* k, Handle
>         protection_domain, Handle classData, TRAPS) {
>         ? ?if (k->class_loader() != nullptr &&
>         ? ? ? ?k->class_loader() !=
>         SystemDictionary::java_platform_loader() &&
>         ? ? ? ?k->class_loader() !=
>         SystemDictionary::java_system_loader()) {
>         @@ -1125,9 +1125,11 @@ void
>         java_lang_Class::create_scratch_mirror(Klass* k, Handle
>         protection_domain,
>         ? ? ?return;
>         ? ?}
>
>         - ?Handle classData; // set to null. Will be reinitialized at
>         runtime
>         + ?//Handle classData; // set to null. Will be reinitialized
>         at runtime
>         ? ?Handle mirror;
>         ? ?Handle comp_mirror;
>         ? ?allocate_mirror(k, /*is_scratch=*/true, protection_domain,
>         classData, mirror, comp_mirror, CHECK);
>
>         ? ?if (comp_mirror() != nullptr) {
>         diff --git a/src/hotspot/share/classfile/javaClasses.hpp
>         b/src/hotspot/share/classfile/javaClasses.hpp
>         index bc49a0861a7..7ec2a2556dd 100644
>         --- a/src/hotspot/share/classfile/javaClasses.hpp
>         +++ b/src/hotspot/share/classfile/javaClasses.hpp
>         @@ -263,7 +263,7 @@ class java_lang_Class : AllStatic {
>
>         ? ?// Archiving
>         ? ?static void serialize_offsets(SerializeClosure* f)
>         NOT_CDS_RETURN;
>         - ?static void create_scratch_mirror(Klass* k, Handle
>         protection_domain, TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>         + ?static void create_scratch_mirror(Klass* k, Handle
>         protection_domain, Handle classData, TRAPS)
>         NOT_CDS_JAVA_HEAP_RETURN;
>         ? ?static bool restore_archived_mirror(Klass *k, Handle
>         class_loader, Handle module,
>         ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Handle protection_domain,
>         ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?TRAPS)
>         NOT_CDS_JAVA_HEAP_RETURN_(false);
>
>         But this resulted in a different exception:
>
>         Exception in thread "main" java.lang.ExceptionInInitializerError
>         at com.redhat.leyden.Main.main(Main.java:7)
>         Caused by: java.lang.invoke.WrongMethodTypeException: handle's
>         method type (WildFlyElytronBaseProvider,Service)void but found
>         (WildFlyElytronBaseProvider,Service)void
>         at
>         java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>         at
>         java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>         at
>         java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
>         at
>         org.wildfly.security.WildFlyElytronBaseProvider$$Lambda/0x80000000c.accept(Unknown
>         Source)
>         at
>         org.wildfly.security.WildFlyElytronBaseProvider.putMakedPasswordImplementations(WildFlyElytronBaseProvider.java:112)
>         at
>         org.wildfly.security.WildFlyElytronBaseProvider.putPasswordImplementations(WildFlyElytronBaseProvider.java:107)
>         at
>         org.wildfly.security.password.WildFlyElytronPasswordProvider.<init>(WildFlyElytronPasswordProvider.java:43)
>         at
>         org.wildfly.security.password.WildFlyElytronPasswordProvider.<clinit>(WildFlyElytronPasswordProvider.java:36)
>         ... 1 more
>
>         The exception message is strange because the handle's method
>         type and the expected type are both symbolically the same.
>         I am debugging this exception at the moment.
>         Thanks,
>         - Ashutosh Mehra
>
>
>         On Wed, Sep 11, 2024 at 6:03?AM Andrew Dinn <adinn at redhat.com>
>         wrote:
>
>             Oops, sorry, I debugged this a few days ago! Correction to
>             a few details:
>
>             On 11/09/2024 10:39, Andrew Dinn wrote:
>             > A crash due to an NPE was observed in the Infinispan
>             (Data Grid) server
>             > app when deployed using the Leyden EA. The crash still
>             manifests with
>             > the latest premain code. The crash happens below an
>             application call
>             > which employs a method reference as argument
>             >
>             > putMakedPasswordImplementations(this::putService, this);
>
>             The called method in turn calls consumer.accept
>
>             ? ? ? ? ? ? ?consumer.accept(new Service(provider,
>             PASSWORD_FACTORY_TYPE, algorithm,
>             "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>             emptyList,
>             emptyMap));
>
>             which enters enters MethodHandleNative::linkDynamicConstant()
>
>             > Debugging shows that the call to linkDynamicConstant()
>             returns null.
>             >
>             > A simple reproducer for the problem is available as a
>             maven project on
>             > github:
>             >
>             > https://github.com/tristantarrant/elytron-leyden
>             <https://urldefense.com/v3/__https://github.com/tristantarrant/elytron-leyden__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZaZr1akQ$>
>             >
>             > The ReadMe provides an explanation of how to reproduce
>             the problem. I
>             > did so and the debugged to find out some of the details
>             of what is
>             > happening (see below) but did not fully clarify the
>             problem. Help from
>             > someone more conversant with the ins and outs of method
>             handle
>             > bootstraps in premain would be welcome. Details follow.
>             >
>             > regards,
>             >
>             >
>             > Andrew Dinn
>             > -----------
>             >
>             > I downloaded the git repo and attached the Java sources
>             using Maven command
>             >
>             >? ? $ mvn dependency:sources
>             >
>             > Having manifested the crash by following the
>             instructions in the README
>             > I reran the leyden JVM under gdb using the following
>             commands to enable
>             > Java debugging
>             >
>             > $ gdb ${LEYDEN_HOME}/bin/java
>             > (gdb) cd /path/to/mvn/project
>             > (gdb) run
>             >
>             -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
>
>             > -classpath
>             >
>             /home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/2.5.1.
>             <https://urldefense.com/v3/__http://2.5.1.__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhauJ-RjcQ$>Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar
>             -XX:CacheDataStore=elytron.aot com.redhat.leyden.Main
>             >
>             > The problem manifests at
>             WildflyElytronBaseProvider.java:112 in method
>             > WildflyElytronBaseProvider::putMakedPasswordImplementations
>
>             ? ? ?static void
>             putMakedPasswordImplementations(Consumer<Service>
>             consumer, Provider provider) {
>             ? ? ? ? ?for (String algorithm : MASKED_ALGORITHMS) {
>             ? ? ? ? ? ? ?consumer.accept(new Service(provider,
>             PASSWORD_FACTORY_TYPE, algorithm,
>             "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>             emptyList,
>             emptyMap)); <== NPE under this call
>             ? ? ? ? ?}
>
>
>             > The source code for this method can be found in the
>             following source jar
>             >
>             >
>             >
>             ${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar
>             >
>             > (where M2_REPO will normally be ~/.m2/repository)
>             >
>             > Stepping into accept eventually enters
>             MethodHandleNative::linkDynamicConstant
>             > which in turn enters into
>             ConstantBootstraps.makeConstant(). The caller
>             > Class at this point is a lambda class which prints as
>             >
>             org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c
>             >
>             > Several steps further the code enters
>             BootstrapMethodInvoker::invoke
>             > (below the app method call but via 3 hidden frames) with
>             bootstrapMethod
>             > bound to a DirectMethodHandle. After several more steps
>             this enters
>             > DirectMethodHandle$Holder.invokeStatic which in turn calls
>             > MethodHandles::classData(Lookup,String,Class).
>             >
>             > At this point caller is a MethodHandleLookup for the
>             lambda class
>             > Lambda/0x800000000c mentioned above. The following call
>             >
>             >? ???????? Object classdata =
>             classData(caller.lookupClass());
>             >
>             > returns null to DirectMethodHandle$Holder.invokeStatic
>             which pops the
>             > same result back out to BootstrapMethodInvoker::invoke
>             at line 90
>             >
>             >? ??????????????? if (type instanceof Class<?> c) {
>             >? ??????????????????? result =
>             bootstrapMethod.invoke(caller, name, c);
>             > <== null
>             >
>             > This null result pops back out as the value for the call to
>             > BootstrapMethodInvoker.invoke(),
>             ConstantBootstraps.makeConstant() and
>             > MethodHandleNative::linkDynamicConstant().
>             >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240916/256efa09/attachment.htm>

From heidinga at openjdk.org  Tue Sep 17 13:37:17 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 17 Sep 2024 13:37:17 GMT
Subject: RFR: Add Premain EA link, Premain JEP links,
 link to training run doc
In-Reply-To: <-QyLFel9ZXkWpKPXYtPkHnH0hT43XnSi9shFLcpRqi8=.7dcd0b5e-e2b4-471f-abf3-94e98618ca65@github.com>
References: <-QyLFel9ZXkWpKPXYtPkHnH0hT43XnSi9shFLcpRqi8=.7dcd0b5e-e2b4-471f-abf3-94e98618ca65@github.com>
Message-ID: <nMmyMHHKZK30GZmxYdW6a82hv2zLG4pLrdZisfF9PxQ=.37ab9ee2-d648-4558-9a56-5d45d023f34d@github.com>

On Tue, 17 Sep 2024 02:29:15 GMT, John R Rose <jrose at openjdk.org> wrote:

> Some adds to the index page:
> 
>  - premain JEP and EA links
>  - link to Dan's doc about training runs
> 
> One thing that baffled me a bit is the `<br/>` elements in the markdown.  These seem to be either hand-inserted as an attempt to do line length control, or else they are artifacts of an old cut-and-paste. Do we really want them?  If so, can we put in a comment in the markdown that says how to maintain them, please?

looks good to me

-------------

Marked as reviewed by heidinga (Committer).

PR Review: https://git.openjdk.org/leyden-docs/pull/4#pullrequestreview-2309786718

From duke at openjdk.org  Tue Sep 17 15:41:47 2024
From: duke at openjdk.org (duke)
Date: Tue, 17 Sep 2024 15:41:47 GMT
Subject: git: openjdk/leyden-docs: master: Add Premain EA link,
 Premain JEP links, link to training run doc (#4)
Message-ID: <29824c19-f779-4765-aff4-2a27dfe54194@openjdk.org>

Changeset: 2faaf6e8
Branch: master
Author:    John Rose <rose00 at mac.com>
Committer: GitHub <noreply at github.com>
Date:      2024-09-17 08:41:17 +0000
URL:       https://git.openjdk.org/leyden-docs/commit/2faaf6e80b43e953320a6461da691546f338f901

Add Premain EA link, Premain JEP links, link to training run doc (#4)

Co-authored-by: John Rose <jrose at openjdk.org>

! site/_index.md


From jrose at openjdk.org  Tue Sep 17 15:44:15 2024
From: jrose at openjdk.org (John R Rose)
Date: Tue, 17 Sep 2024 15:44:15 GMT
Subject: Withdrawn: Add Premain EA link, Premain JEP links,
 link to training run doc
In-Reply-To: <-QyLFel9ZXkWpKPXYtPkHnH0hT43XnSi9shFLcpRqi8=.7dcd0b5e-e2b4-471f-abf3-94e98618ca65@github.com>
References: <-QyLFel9ZXkWpKPXYtPkHnH0hT43XnSi9shFLcpRqi8=.7dcd0b5e-e2b4-471f-abf3-94e98618ca65@github.com>
Message-ID: <xTu1UZDLGQIqo_UaXgRYIZ-yKZJK-naEfYI_unTRHpw=.18629b38-a616-4e97-ba9d-6d585052fc1d@github.com>

On Tue, 17 Sep 2024 02:29:15 GMT, John R Rose <jrose at openjdk.org> wrote:

> Some adds to the index page:
> 
>  - premain JEP and EA links
>  - link to Dan's doc about training runs
> 
> One thing that baffled me a bit is the `<br/>` elements in the markdown.  These seem to be either hand-inserted as an attempt to do line length control, or else they are artifacts of an old cut-and-paste. Do we really want them?  If so, can we put in a comment in the markdown that says how to maintain them, please?

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/leyden-docs/pull/4

From ioi.lam at oracle.com  Tue Sep 17 15:54:20 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Tue, 17 Sep 2024 08:54:20 -0700
Subject: AOTHolder pattern for caching heap objects
In-Reply-To: <AF9C5EC9-4CA7-444B-8D0D-540F3132AA93@oracle.com>
References: <8394149d-6ec1-4b52-a454-14d40dbf8223@oracle.com>
 <AF9C5EC9-4CA7-444B-8D0D-540F3132AA93@oracle.com>
Message-ID: <b52242b2-d6a5-4b68-b7e4-9ebf84418c78@oracle.com>


On 8/29/24 10:39 AM, Claes Redestad wrote:
> Hi,
>
> I think everyone will be happy to see CDS.initializeFromArchive go!
>
> Some random thoughts:
> - Rather than hardcoding on AOTHolder should we put some internal marker annotation to signal intent? E.g @Archivable
> - I wonder if this initialization indirection could be generalized using StableValues[1] - along with a marker annotation. That would feel very streamlined and avoid the need for most Holder classes (which is a design center of SVs).
>
> /Claes
>
I am using the AOTHolder pattern so that I can break the circularity 
dependencies of <clinit> methods to archive a subset of static fields. 
Initially, I want to make everything simple, especially for JEP 483, so 
I am hesitant to add annotations, etc.

It seems StableValues (https://openjdk.org/jeps/8312611) will be a more 
general solution that also solves my problem. So yes, I think we should 
consider how StableValues can work in the Leyden context.

Thanks

- Ioi

>> 29 aug. 2024 kl. 19:10 skrev ioi.lam at oracle.com:
>>
>> For the development of JDK-8293336 [1], I am experimenting with a pattern of Java code to indicate what heap objects should be stored in the AOT cache. This code has been pushed to the premain branch.
>>
>> It looks like this [2]:
>>
>> class java.lang.invoke.MethodType {
>>
>>      static class AOTHolder {
>>          private static final @Stable MethodType[] objectOnlyTypes = new MethodType[20];
>>          private static @Stable HashMap<MethodType,MethodType> archivedMethodTypes;
>>      }
>>
>> Essentially the class MethodType$AOTHolder will be stored in its "already initialized" state in the AOT cache. In the production run, MethodType$AOTHolder.<clinit> will NOT be run. Its static fields are already initialized and point to the objects that were created during the assembly phase.
>>
>> Currently, the JVM is hard-wired to recognize only a few known AOTHolder classes. This pattern is used strictly for the AOT-caching of MethodType.internTable.
>>
>> I want to hear people's reaction to this. I think other internal JDK classes can use a similar pattern as well.
>>
>> (In the long term, we will need a more generalized way (a.k.a. the "Scrambled Egg API"), but I need to have a mechanism that works for the short term).
>>
>> ***
>>
>> The reason I needed to use the AOTHolder pattern is to remove this horrible hack [3]. (It's now removed from the premain branch). You can see more info in the comments of [3], but the gist is:
>>
>> - The old way of CDS heap object caching depends on re-executing the <clinit> methods of classes that want to cache heap objects
>>
>> - These classes would call CDS.initializeFromArchive() to fetch the cached objects.
>>
>> - Before CDS.initializeFromArchive() returns the objects, it wants to initialize all the classes of these objects (or else the caller would end up with an object whose class is not yet initialized)
>>
>> - This scheme breaks down when several classes want to cache heap objects, and their <clinit> intertwine with each other.
>>
>> The old code in [3] tries to work around a NullPointerException that happens due to the intertwining. That is certainly not a sustainable approach.
>>
>> ***
>>
>> The AOTHolder pattern tries to accomplish two things
>>
>> - Clearly identify what objects should be AOT-cached. In the case of MethodType.java, I moved only two of its many fields into its AOTHolder inner class.
>>
>> - Cache the static fields in all the AOTHolder classes as a single snapshot. Avoid the need to run <clinit> so we don't need to worry about execution order, etc.
>>
>> ======
>>
>> [1] https://bugs.openjdk.org/browse/JDK-8293336
>>
>> [2] https://github.com/openjdk/leyden/blob/e33ecb3ec42d142569227b4bd1987124e5551cde/src/java.base/share/classes/java/lang/invoke/MethodType.java#L438-L441
>>
>> [3] https://github.com/openjdk/leyden/blob/3a84df9d9860e743684e335282e3910b14cc982b/src/hotspot/share/cds/heapShared.cpp#L1415-L1466
>>

From macarte at openjdk.org  Tue Sep 17 17:34:24 2024
From: macarte at openjdk.org (Mat Carter)
Date: Tue, 17 Sep 2024 17:34:24 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v3]
In-Reply-To: <dqgWT3miGenFyfa8GJFNrhet5_eON-OhTkmDsKwCB14=.d556d5be-3074-4c4b-ac42-13f38c86b876@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
 <sGbZxClkC1gVEtSjILXVTarW-ns_8Vv3Ylgbgq7rLqY=.29b21ee8-da43-44d8-b882-e194f4a79cb3@github.com>
 <XGXLVDzhpqxG3ouwhFzchZTczFykwJvyIeBcMkkjCxI=.8e31f6dc-d961-4a05-a88e-230898b0563f@github.com>
 <dqgWT3miGenFyfa8GJFNrhet5_eON-OhTkmDsKwCB14=.d556d5be-3074-4c4b-ac42-13f38c86b876@github.com>
Message-ID: <SNvsrCwXS3cTqLYuNlto0PZ_XTjgakFR15FHQbMJ5PQ=.31beed4e-dbc6-435b-ae56-c473f5d45c82@github.com>

On Tue, 17 Sep 2024 04:33:38 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/services/diagnosticCommand.hpp line 410:
>> 
>>> 408:     static const JavaPermission permission() {
>>> 409:     JavaPermission p = {"java.lang.management.ManagementPermission",
>>> 410:                         "monitor", nullptr};
>> 
>> Should this be 'monitor' or 'control' (or something else)?
>
> I think "monitor" is appropriate (used also for dumping heap, etc). The API says "control" is to "control the runtime characteristics of the Java virtual machine", but we aren't really modifying the runtime characteristics.

Yes in v1 of this PR, ending the training run would cause the application to exit, hence our though on 'control', but as this is no longer the case, 'monitor' is more appropriate

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1763627882

From macarte at openjdk.org  Tue Sep 17 17:38:20 2024
From: macarte at openjdk.org (Mat Carter)
Date: Tue, 17 Sep 2024 17:38:20 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v5]
In-Reply-To: <o5nLJ9rBREcqmjM_6CuPLqt_laP0lgq3lHXMfq3KQK8=.417ac24d-a36d-405e-8b16-a73315bd2bb6@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
 <O62aA2NFpuIOziFFeYmSzfkY7ZkI3n127LHUK3ZyYlI=.822b9602-be51-4c78-b36d-8a4747d452f0@github.com>
 <o5nLJ9rBREcqmjM_6CuPLqt_laP0lgq3lHXMfq3KQK8=.417ac24d-a36d-405e-8b16-a73315bd2bb6@github.com>
Message-ID: <p-oHQ-LBrxpAcQ_s8fotwpHXFotUp0JnIyFBvpMcy8o=.a1bf4e4b-149a-42b3-9dc8-8d75ad425661@github.com>

On Tue, 17 Sep 2024 04:29:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed extra space left over from reverted change
>
> src/hotspot/share/opto/parse1.cpp line 1215:
> 
>> 1213:   }
>> 1214: 
>> 1215:   if (CDSConfig::is_dumping_preimage_static_archive_with_triggers() && method()->is_end_training_trigger()) {
> 
> Do we come here also if `method()` is being inlined by C2?

It does, I tested inlining manually and proved that the method was inlined and still triggering, I'll see if I can add a test case so that if the inlining code path changes the test failure will direct us to add the appropriate code to the new code path

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1763632869

From mr at openjdk.org  Tue Sep 17 19:55:40 2024
From: mr at openjdk.org (Mark Reinhold)
Date: Tue, 17 Sep 2024 19:55:40 GMT
Subject: git: openjdk/leyden-docs: master: 2 new changesets
Message-ID: <39ae15f5-c130-4bc8-b928-8411bbafa250@openjdk.org>

Changeset: 6a01cae2
Branch: master
Author:    Mark Reinhold <mr at openjdk.org>
Date:      2024-09-17 15:50:01 +0000
URL:       https://git.openjdk.org/leyden-docs/commit/6a01cae2165acde7b0b6a4a9d85513dc5f53b202

Rework main page

! site/_index.md
- site/leyden-jar-200.jpg
+ site/leyden-jar.jpg

Changeset: 35475b30
Branch: master
Author:    Mark Reinhold <mr at openjdk.org>
Date:      2024-09-17 15:51:51 +0000
URL:       https://git.openjdk.org/leyden-docs/commit/35475b30f9b6861128a40c4350b9ffffb5f58fb3

Training Runs note: Fix metadata

! site/notes/05-training-runs.md


From asmehra at redhat.com  Tue Sep 17 21:49:40 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Tue, 17 Sep 2024 17:49:40 -0400
Subject: premain: Crash in Infinispan server code caused by NPE under
 MethodHandleNative::linkDynamicConstant
In-Reply-To: <0d22d580-39a1-4105-a50e-8a74a555090d@oracle.com>
References: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
 <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>
 <CAKt0pySztvwsadtrqjai6XwakAWq_v_o8men4aopLo4X-0azyQ@mail.gmail.com>
 <CAKt0pyQ44E+npyUW35Zhxg+PfBgF2yuNgS61gj1GGj=aLGTJXw@mail.gmail.com>
 <CAKt0pyT48uPH6rUL7bEJ2rtWqNdNL34DWBJ2SDaHwYfVxURnQw@mail.gmail.com>
 <0d22d580-39a1-4105-a50e-8a74a555090d@oracle.com>
Message-ID: <CAKt0pyQ0Cwiwy1ZUX8ua0oYVjHdPA5Md0Lt2zDytUUYfMYfmSg@mail.gmail.com>

Hi Ioi,
I am wondering if we can workaround class circularity issues by recording
class initialization order during training run
and use that to guide the initialization during assembly phase.
Does that make sense?

Thanks,
- Ashutosh Mehra


On Tue, Sep 17, 2024 at 1:11?AM <ioi.lam at oracle.com> wrote:

> Hi Ashutosh,
>
> So this looks like a potential bug (or feature) in the core lib code. When
> CDS forcefully initializes a class in an unexpected (or untested) order,
> the "initialization soup" fails.
>
> Perhaps a work-around would be to make some harmless calls at the place
> where CDS was calling into MethodType.createArchivedObjects(). E.g., do
> something like this:
>
> +    if (CDSConfig::is_dumping_invokedynamic()) {
> +       // call into Java: jdk.internal.misc::warmupInvokeDynamic();
> +   }
>     // Rewrite and link classes
>     log_info(cds)("Rewriting and linking classes ...");
>
> Maybe you can add a new Lambda expressions, MethodHandle invocations, etc,
> that would hopefully cause PrimitiveClassDescImpl and friends to be
> initialized in their natural order.
>
> Or call class.forName("java.lang.constant.ConstantDescs") ??
>
> BTW, you can see my comments in
> AOTClassInitializer::is_forced_preinit_class():
>
>     // TODO:
>     // This is needed since JDK-8338532. Without this, when
>     // archived heap objects are used, the class init order is not
>     // expected by the jdk/internal/constant bootstrap code and we
>     // will get a null pointer exception.
>     //
>     // When bootstraping has intricated/fragile order, it's probably
>     // better to archive all related classes in an initialized state
>     // (i.e., take a snapshot). The existing approach in
>     // heapShared::resolve_or_init_classes_for_subgraph_of() won't work.
>     "jdk/internal/constant/PrimitiveClassDescImpl",
>     "jdk/internal/constant/ReferenceClassDescImpl",
>     "java/lang/constant/ConstantDescs",
>     "sun/invoke/util/Wrapper",
>
> I was having a similar circularity issue (but in production time) and I
> just added enough classes to make the NPE go away. For your test case, if
> you manage to fix in in the assembly run but run into NPE in production
> run, you might need to add more classes to this list. Yes, it's a hack :-(
>
>
> Thanks
>
> - Ioi
> On 9/13/24 7:05 PM, Ashutosh Mehra wrote:
>
> This is turning out to be a real example of class initialization soup!
> As mentioned during the meeting, I am getting NPE in the assembly phase
> when testing the patch [0] that I proposed in my earlier mail
> using a test case inspired by the Infinispan code.
> NPE occurs when running the class initializer for PrimitiveClassDescImpl
> Interestingly, PrimitiveClassDescImpl is "forcefully" initialized by
> MetaspaceShared::link_shared_classes().
>
> I couldn't get a stack trace so I relied on exception logs (using
> -Xlog:exceptions=trace) to find the cause which indicate following frames
> on the stack:
>
> [0]
> jdk/internal/constant/MethodTypeDescImpl::validateArgument(Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/ClassDesc; @
> bci 1
> [1]
> jdk/internal/constant/MethodTypeDescImpl::ofTrusted(Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljdk/internal/constant/MethodTypeDescImpl; @
> bci 27
> [2]
> java/lang/constant/ConstantDescs::ofConstantBootstrap(Ljava/lang/constant/ClassDesc;Ljava/lang/String;Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/DirectMethodHandleDesc; @
> bci 47
> [3] java/lang/constant/ConstantDescs::<clinit> @ bci 664
> [4]
> jdk/internal/constant/PrimitiveClassDescImpl::<init>(Ljava/lang/String;)V @
> bci 1
> [5]
> jdk/internal/constant/PrimitiveClassDescImpl::<clinit>(Ljava/lang/String;)V @
> bci 6
>
> Notice that invocation of PrimitiveClassDescImpl::<clinit> results in
> initialization of ConstantDescs class (see frame 3).
> ConstantDescs::<clinit> @ 664 corresponds to following java code:
>
>     public static final DirectMethodHandleDesc BSM_CLASS_DATA_AT
>             = ofConstantBootstrap(CD_MethodHandles, "classDataAt",
>             CD_Object, CD_int);
>
> The last parameter CD_int is initialized as:
>
>     public static final ClassDesc CD_int = PrimitiveClassDescImpl.CD_int;
>
> So, its value is obtained from PrimitiveClassDescImpl.CD_int which hasn't
> been initialized properly yet. As a result ConstantDescs::CD_int is
> assigned null which results in MethodTypeDescImpl::validateArgument
> throwing NPE later.
> There is a clear class initialization circularity involving
> PrimitiveClassDescImpl and ConstantDescs, and the result depends on which
> class gets initialized first.
>
> Without my patch this issue is not seen because PrimitiveClassDescImpl
> has already been initialized by the time
> MetaspaceShared::link_shared_classes() is called.
> Its initialization is triggered by the call to
> MethodType::createArchivedObjects().
> It also explains why my patch introduced this issue because it effectively
> moved the call to MethodType::createArchivedObjects() after
> MetaspaceShared::link_shared_classes().
>
> [0]
> https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>
> Thanks,
> - Ashutosh Mehra
>
>
> On Wed, Sep 11, 2024 at 3:12?PM Ashutosh Mehra <asmehra at redhat.com> wrote:
>
>> Regarding the WrongMethodTypeException that I mentioned in my previous
>> email (see pt 3),
>> this exception happens when lambda proxy class attempts to invoke the
>> MethodHandle it obtained from the classData:
>>
>>   public void accept(java.lang.Object);
>>     descriptor: (Ljava/lang/Object;)V
>>     flags: (0x0001) ACC_PUBLIC
>>     Code:
>>       stack=3, locals=2, args_size=2
>>          0: ldc           #26                 // Dynamic
>> #0:_:Ljava/lang/invoke/MethodHandle;
>>          2: aload_0
>>          3: getfield      #13                 // Field
>> arg$1:Lorg/wildfly/security/WildFlyElytronBaseProvider;
>>          6: aload_1
>>          7: checkcast     #28                 // class
>> java/security/Provider$Service
>>         10: invokevirtual #34                 // Method
>> java/lang/invoke/MethodHandle.invokeExact:(Lorg/wildfly/security/WildFlyElytronBaseProvider;Ljava/security/Provider$Service;)V
>>         13: return
>>
>> The scenario is during the assembly phase as part of the indy resolution
>> the MethodHandle for which the exception is thrown gets created.
>> Normally MethodHandle's type gets added in MethodType::internTable but
>> by the time indy resolution happens, JVM has already taken
>> snapshot of the MethodType::internTable through an upcall to
>> MethodType::createArchivedObjects().
>> As a result the AOTCache ends up with the MethodType object which is not
>> in AOTHolder.archivedMethodTypes.
>>
>> During the production run, when the jvm invokes the MethodHandle, it
>> searches for the MethodType corresponding to the signature passed at the
>> callsite.
>> As expected, it fails to find it in the AOTHolder.archivedMethodTypes,
>> so it creates a new instance of the MethodType.
>> But Invokers.checkExactType() relies on the MethodHandle's type to be
>> the same object as the MethodType object passed as parameter.
>>
>>     static void checkExactType(MethodHandle mhM, MethodType expected) {
>>         MethodType targetType = mh.type();
>>         if (targetType != expected)
>>             throw newWrongMethodTypeException(targetType, expected);
>>     }
>>
>> Hence, it throws WrongMethodTypeException though the two MT objects have
>> the same signature.
>>
>> To handle this scenario, I changed the order of indy resolution and upcall
>> to MethodType::createArchivedObjects() as:
>>
>> diff --git a/src/hotspot/share/cds/metaspaceShared.cpp
>> b/src/hotspot/share/cds/metaspaceShared.cpp
>> index df4bcadefa3..457716cac5b 100644
>> --- a/src/hotspot/share/cds/metaspaceShared.cpp
>> +++ b/src/hotspot/share/cds/metaspaceShared.cpp
>> @@ -751,6 +751,20 @@ void MetaspaceShared::link_shared_classes(bool
>> jcmd_request, TRAPS) {
>>    if (CDSConfig::is_dumping_final_static_archive()) {
>>      FinalImageRecipes::apply_recipes(CHECK);
>>    }
>> +
>> +#if INCLUDE_CDS_JAVA_HEAP
>> +  if (CDSConfig::is_dumping_invokedynamic()) {
>> +    // This makes sure that the MethodType and MethodTypeForm tables
>> won't be updated
>> +    // concurrently when we are saving their contents into a side table.
>> +    assert(CDSConfig::allow_only_single_java_thread(), "Required");
>> +
>> +    JavaValue result(T_VOID);
>> +    JavaCalls::call_static(&result, vmClasses::MethodType_klass(),
>> +                           vmSymbols::createArchivedObjects(),
>> +                           vmSymbols::void_method_signature(),
>> +                           CHECK);
>> +  }
>> +#endif
>>  }
>>
>> Note that indy resolution happens as part of FinalImageRecipes::apply_recipes(CHECK)
>> which is now invoked before the upcall to createArchivedObjects().
>> With this change I am able to run the application without any exceptions.
>> My complete patch can be seen here:
>> https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>> I will do more testing with this patch.
>>
>> @Ioi Lam <ioi.lam at oracle.com> do you have any feedback on this patch.
>>
>> Thanks,
>> - Ashutosh Mehra
>>
>>
>>
>> On Wed, Sep 11, 2024 at 10:14?AM Ashutosh Mehra <asmehra at redhat.com>
>> wrote:
>>
>>> Hi Andrew,
>>> Thanks for sharing the initial investigation.
>>> I have been looking into this and have a few of things to add to your
>>> analysis:
>>>
>>> 1.  As you mentioned the classData for the lambda
>>> class WildFlyElytronBaseProvider$$Lambda is null.
>>> The classData is stored in the mirror object of the InstanceKlass when
>>> the class is defined through JVM_LookupDefineClass.
>>> However, when we create the scratch mirror object (which get stored in
>>> the AOT cache) the classData is not populated.
>>> See
>>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp#L1128-L1131
>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp*L1128-L1131__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhbKjzG3gw$>
>>>
>>>   Handle classData; // set to null. Will be reinitialized at runtime
>>>   Handle mirror;
>>>   Handle comp_mirror;
>>>   allocate_mirror(k, /*is_scratch=*/true, protection_domain, classData,
>>> mirror, comp_mirror, CHECK);
>>>
>>> So this explains why the call to classData(caller.lookupClass())
>>> returned null.
>>>
>>> 2. In the mainline there is a check in InnerClassLambdaMetafactory.java
>>> for the particular code pattern used by the application.
>>> If this code pattern is found then the lambda proxy class is not
>>> included in the CDS archive.
>>> See
>>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L163-L170
>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L163-L170__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZl2S9tQg$>
>>> and
>>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L246
>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L246__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhYsI3Xx0g$>
>>>
>>>         // If the target class invokes a protected method inherited from
>>> a
>>>         // superclass in a different package, or does 'invokespecial',
>>> the
>>>         // lambda class has no access to the resolved method, or does
>>>         // 'invokestatic' on a hidden class which cannot be resolved by
>>> name.
>>>         // Instead, we need to pass the live implementation method
>>> handle to
>>>         // the proxy class to invoke directly. (javac prefers to avoid
>>> this
>>>         // situation by generating bridges in the target class)
>>>         useImplMethodHandle =
>>> (Modifier.isProtected(implInfo.getModifiers()) &&
>>>                                !VerifyAccess.isSamePackage(targetClass,
>>> implInfo.getDeclaringClass())) ||
>>>                                implKind ==
>>> MethodHandleInfo.REF_invokeSpecial ||
>>>                                implKind ==
>>> MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>>>
>>> In premain lambda proxy classes get included in the AOT cache as a
>>> result of indy resolution and that mechanism doesn't have this kind of
>>> check.
>>>
>>> 3. For the null classData problem mentioned above, I tried to fix it by
>>> storing classData in the scratch mirror using the following patch:
>>>
>>> diff --git a/src/hotspot/share/classfile/javaClasses.cpp
>>> b/src/hotspot/share/classfile/javaClasses.cpp
>>> index bd8141adbcc..41766e98093 100644
>>> --- a/src/hotspot/share/classfile/javaClasses.cpp
>>> +++ b/src/hotspot/share/classfile/javaClasses.cpp
>>> @@ -1094,9 +1094,9 @@ void java_lang_Class::create_mirror(Klass* k,
>>> Handle class_loader,
>>>      }
>>>      if (CDSConfig::is_dumping_heap()) {
>>>        if (CDSConfig::is_dumping_protection_domains()) {
>>> -        create_scratch_mirror(k, protection_domain, CHECK);
>>> +        create_scratch_mirror(k, protection_domain, classData, CHECK);
>>>        } else {
>>> -        create_scratch_mirror(k, Handle() /* null protection_domain*/,
>>> CHECK);
>>> +        create_scratch_mirror(k, Handle() /* null protection_domain*/,
>>> classData, CHECK);
>>>        }
>>>      }
>>>    } else {
>>> @@ -1117,7 +1117,7 @@ void java_lang_Class::create_mirror(Klass* k,
>>> Handle class_loader,
>>>  // Note: we archive the "scratch mirror" instead of k->java_mirror(),
>>> because the
>>>  // latter may contain dumptime-specific information that cannot be
>>> archived
>>>  // (e.g., ClassLoaderData*, or static fields that are modified by Java
>>> code execution).
>>> -void java_lang_Class::create_scratch_mirror(Klass* k, Handle
>>> protection_domain, TRAPS) {
>>> +void java_lang_Class::create_scratch_mirror(Klass* k, Handle
>>> protection_domain, Handle classData, TRAPS) {
>>>    if (k->class_loader() != nullptr &&
>>>        k->class_loader() != SystemDictionary::java_platform_loader() &&
>>>        k->class_loader() != SystemDictionary::java_system_loader()) {
>>> @@ -1125,9 +1125,11 @@ void
>>> java_lang_Class::create_scratch_mirror(Klass* k, Handle protection_domain,
>>>      return;
>>>    }
>>>
>>> -  Handle classData; // set to null. Will be reinitialized at runtime
>>> +  //Handle classData; // set to null. Will be reinitialized at runtime
>>>    Handle mirror;
>>>    Handle comp_mirror;
>>>    allocate_mirror(k, /*is_scratch=*/true, protection_domain, classData,
>>> mirror, comp_mirror, CHECK);
>>>
>>>    if (comp_mirror() != nullptr) {
>>> diff --git a/src/hotspot/share/classfile/javaClasses.hpp
>>> b/src/hotspot/share/classfile/javaClasses.hpp
>>> index bc49a0861a7..7ec2a2556dd 100644
>>> --- a/src/hotspot/share/classfile/javaClasses.hpp
>>> +++ b/src/hotspot/share/classfile/javaClasses.hpp
>>> @@ -263,7 +263,7 @@ class java_lang_Class : AllStatic {
>>>
>>>    // Archiving
>>>    static void serialize_offsets(SerializeClosure* f) NOT_CDS_RETURN;
>>> -  static void create_scratch_mirror(Klass* k, Handle protection_domain,
>>> TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>>> +  static void create_scratch_mirror(Klass* k, Handle protection_domain,
>>> Handle classData, TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>>>    static bool restore_archived_mirror(Klass *k, Handle class_loader,
>>> Handle module,
>>>                                        Handle protection_domain,
>>>                                        TRAPS)
>>> NOT_CDS_JAVA_HEAP_RETURN_(false);
>>>
>>> But this resulted in a different exception:
>>>
>>> Exception in thread "main" java.lang.ExceptionInInitializerError
>>> at com.redhat.leyden.Main.main(Main.java:7)
>>> Caused by: java.lang.invoke.WrongMethodTypeException: handle's method
>>> type (WildFlyElytronBaseProvider,Service)void but found
>>> (WildFlyElytronBaseProvider,Service)void
>>> at
>>> java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>>> at java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>>> at
>>> java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
>>> at
>>> org.wildfly.security.WildFlyElytronBaseProvider$$Lambda/0x80000000c.accept(Unknown
>>> Source)
>>> at
>>> org.wildfly.security.WildFlyElytronBaseProvider.putMakedPasswordImplementations(WildFlyElytronBaseProvider.java:112)
>>> at
>>> org.wildfly.security.WildFlyElytronBaseProvider.putPasswordImplementations(WildFlyElytronBaseProvider.java:107)
>>> at
>>> org.wildfly.security.password.WildFlyElytronPasswordProvider.<init>(WildFlyElytronPasswordProvider.java:43)
>>> at
>>> org.wildfly.security.password.WildFlyElytronPasswordProvider.<clinit>(WildFlyElytronPasswordProvider.java:36)
>>> ... 1 more
>>>
>>> The exception message is strange because the handle's method type and
>>> the expected type are both symbolically the same.
>>> I am debugging this exception at the moment.
>>>
>>> Thanks,
>>> - Ashutosh Mehra
>>>
>>>
>>> On Wed, Sep 11, 2024 at 6:03?AM Andrew Dinn <adinn at redhat.com> wrote:
>>>
>>>> Oops, sorry, I debugged this a few days ago! Correction to a few
>>>> details:
>>>>
>>>> On 11/09/2024 10:39, Andrew Dinn wrote:
>>>> > A crash due to an NPE was observed in the Infinispan (Data Grid)
>>>> server
>>>> > app when deployed using the Leyden EA. The crash still manifests with
>>>> > the latest premain code. The crash happens below an application call
>>>> > which employs a method reference as argument
>>>> >
>>>> >          putMakedPasswordImplementations(this::putService, this);
>>>>
>>>> The called method in turn calls consumer.accept
>>>>
>>>>              consumer.accept(new Service(provider,
>>>> PASSWORD_FACTORY_TYPE, algorithm,
>>>> "org.wildfly.security.password.impl.PasswordFactorySpiImpl", emptyList,
>>>> emptyMap));
>>>>
>>>> which enters enters MethodHandleNative::linkDynamicConstant()
>>>>
>>>> > Debugging shows that the call to linkDynamicConstant() returns null.
>>>> >
>>>> > A simple reproducer for the problem is available as a maven project
>>>> on
>>>> > github:
>>>> >
>>>> >    https://github.com/tristantarrant/elytron-leyden
>>>> <https://urldefense.com/v3/__https://github.com/tristantarrant/elytron-leyden__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZaZr1akQ$>
>>>> >
>>>> > The ReadMe provides an explanation of how to reproduce the problem. I
>>>> > did so and the debugged to find out some of the details of what is
>>>> > happening (see below) but did not fully clarify the problem. Help
>>>> from
>>>> > someone more conversant with the ins and outs of method handle
>>>> > bootstraps in premain would be welcome. Details follow.
>>>> >
>>>> > regards,
>>>> >
>>>> >
>>>> > Andrew Dinn
>>>> > -----------
>>>> >
>>>> > I downloaded the git repo and attached the Java sources using Maven
>>>> command
>>>> >
>>>> >    $ mvn dependency:sources
>>>> >
>>>> > Having manifested the crash by following the instructions in the
>>>> README
>>>> > I reran the leyden JVM under gdb using the following commands to
>>>> enable
>>>> > Java debugging
>>>> >
>>>> > $ gdb ${LEYDEN_HOME}/bin/java
>>>> > (gdb) cd /path/to/mvn/project
>>>> > (gdb) run
>>>> > -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
>>>> > -classpath
>>>> >
>>>> /home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/
>>>> 2.5.1.
>>>> <https://urldefense.com/v3/__http://2.5.1.__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhauJ-RjcQ$>Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar
>>>> -XX:CacheDataStore=elytron.aot com.redhat.leyden.Main
>>>> >
>>>> > The problem manifests at WildflyElytronBaseProvider.java:112 in
>>>> method
>>>> > WildflyElytronBaseProvider::putMakedPasswordImplementations
>>>>
>>>>      static void putMakedPasswordImplementations(Consumer<Service>
>>>> consumer, Provider provider) {
>>>>          for (String algorithm : MASKED_ALGORITHMS) {
>>>>              consumer.accept(new Service(provider,
>>>> PASSWORD_FACTORY_TYPE, algorithm,
>>>> "org.wildfly.security.password.impl.PasswordFactorySpiImpl", emptyList,
>>>> emptyMap)); <== NPE under this call
>>>>          }
>>>>
>>>>
>>>> > The source code for this method can be found in the following source
>>>> jar
>>>> >
>>>> >
>>>> >
>>>> ${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar
>>>> >
>>>> > (where M2_REPO will normally be ~/.m2/repository)
>>>> >
>>>> > Stepping into accept eventually enters
>>>> MethodHandleNative::linkDynamicConstant
>>>> > which in turn enters into ConstantBootstraps.makeConstant(). The
>>>> caller
>>>> > Class at this point is a lambda class which prints as
>>>> > org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c
>>>> >
>>>> > Several steps further the code enters BootstrapMethodInvoker::invoke
>>>> > (below the app method call but via 3 hidden frames) with
>>>> bootstrapMethod
>>>> > bound to a DirectMethodHandle. After several more steps this enters
>>>> > DirectMethodHandle$Holder.invokeStatic which in turn calls
>>>> > MethodHandles::classData(Lookup,String,Class).
>>>> >
>>>> > At this point caller is a MethodHandleLookup for the lambda class
>>>> > Lambda/0x800000000c mentioned above. The following call
>>>> >
>>>> >           Object classdata = classData(caller.lookupClass());
>>>> >
>>>> > returns null to DirectMethodHandle$Holder.invokeStatic which pops the
>>>> > same result back out to BootstrapMethodInvoker::invoke at line 90
>>>> >
>>>> >                  if (type instanceof Class<?> c) {
>>>> >                      result = bootstrapMethod.invoke(caller, name,
>>>> c);
>>>> > <== null
>>>> >
>>>> > This null result pops back out as the value for the call to
>>>> > BootstrapMethodInvoker.invoke(), ConstantBootstraps.makeConstant()
>>>> and
>>>> > MethodHandleNative::linkDynamicConstant().
>>>> >
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240917/c9bba354/attachment.htm>

From asmehra at openjdk.org  Tue Sep 17 22:23:28 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 17 Sep 2024 22:23:28 GMT
Subject: RFR: Method name AOTClassInitializer::has_non_default_static_fields
 should be has_default_static_fields
Message-ID: <lPpPQfYNMyL-Ra5PItp_6KWqBcM49eXiJXfvDYiWT1I=.b8fa20d6-e357-4536-86bb-17f98c050c3f@github.com>

Trivial change to correct the method name to reflect its implementation.

-------------

Commit messages:
 - Method name AOTClassInitializer::has_non_default_static_fields

Changes: https://git.openjdk.org/leyden/pull/22/files
  Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=22&range=00
  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/leyden/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/22/head:pull/22

PR: https://git.openjdk.org/leyden/pull/22

From iklam at openjdk.org  Tue Sep 17 23:52:19 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 17 Sep 2024 23:52:19 GMT
Subject: RFR: Method name
 AOTClassInitializer::has_non_default_static_fields  should be
 has_default_static_fields
In-Reply-To: <lPpPQfYNMyL-Ra5PItp_6KWqBcM49eXiJXfvDYiWT1I=.b8fa20d6-e357-4536-86bb-17f98c050c3f@github.com>
References: <lPpPQfYNMyL-Ra5PItp_6KWqBcM49eXiJXfvDYiWT1I=.b8fa20d6-e357-4536-86bb-17f98c050c3f@github.com>
Message-ID: <x81sbLPCO-lpBFNOk4VCHO7uOqMHEh_gM8hE6IQgAcg=.210c54b4-d0d6-469c-8368-f1eba6b28b59@github.com>

On Tue, 17 Sep 2024 22:18:26 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> Trivial change to correct the method name to reflect its implementation.

LGTM

-------------

Marked as reviewed by iklam (Committer).

PR Review: https://git.openjdk.org/leyden/pull/22#pullrequestreview-2311360919

From ioi.lam at oracle.com  Tue Sep 17 23:58:46 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Tue, 17 Sep 2024 16:58:46 -0700
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache
Message-ID: <be5c39a2-ede5-48d8-b576-cda34fc9554e@oracle.com>

Hi, this is the 6th PR for JEP 483 - Ahead-of-Time Class Loading & 
Linking [1]

The PR is https://github.com/openjdk/jdk/pull/21049

- When writing heap objects to the AOT cache (currently this is done 
only when dumping "static" CDS archive), avoid using SoftReferences in 
LambdaFormEditor and MethodTypeForm.
- This is a requirement by JDK-8293336 [3] (AOT-linking of invokedynamic 
for lambda expression and string concat), which is the 7th and last PR 
for JEP 483


The plan [2] is to break down JEP 483 in a series of 7 PRs to make it 
easier to review. I will post the other PRs soon.

Thanks

- Ioi

===

[1] https://openjdk.org/jeps/483
[2] https://bugs.openjdk.org/browse/JDK-8331497
[3] https://bugs.openjdk.org/browse/JDK-8293336




From asmehra at openjdk.org  Wed Sep 18 13:36:51 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 18 Sep 2024 13:36:51 GMT
Subject: git: openjdk/leyden: premain: Method name
 AOTClassInitializer::has_non_default_static_fields  should be
 has_default_static_fields
Message-ID: <61d84e67-01fa-4d3e-be9b-f591b09c14a4@openjdk.org>

Changeset: 77811091
Branch: premain
Author:    Ashutosh Mehra <asmehra at openjdk.org>
Date:      2024-09-18 13:36:21 +0000
URL:       https://git.openjdk.org/leyden/commit/7781109154bf2af89854c7e13aa3e160bb82608e

Method name AOTClassInitializer::has_non_default_static_fields  should be has_default_static_fields

Reviewed-by: iklam

! src/hotspot/share/cds/aotClassInitializer.cpp
! src/hotspot/share/cds/aotClassInitializer.hpp


From asmehra at openjdk.org  Wed Sep 18 13:39:26 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 18 Sep 2024 13:39:26 GMT
Subject: Integrated: Method name
 AOTClassInitializer::has_non_default_static_fields  should be
 has_default_static_fields
In-Reply-To: <lPpPQfYNMyL-Ra5PItp_6KWqBcM49eXiJXfvDYiWT1I=.b8fa20d6-e357-4536-86bb-17f98c050c3f@github.com>
References: <lPpPQfYNMyL-Ra5PItp_6KWqBcM49eXiJXfvDYiWT1I=.b8fa20d6-e357-4536-86bb-17f98c050c3f@github.com>
Message-ID: <OKdUaambq8fzu3_7CiT_ZU7TPEY469h7TBlFfzSdw-Q=.d555bfb0-5527-4b82-82e6-c84ddd481f70@github.com>

On Tue, 17 Sep 2024 22:18:26 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> Trivial change to correct the method name to reflect its implementation.

This pull request has now been integrated.

Changeset: 77811091
Author:    Ashutosh Mehra <asmehra at openjdk.org>
URL:       https://git.openjdk.org/leyden/commit/7781109154bf2af89854c7e13aa3e160bb82608e
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

Method name AOTClassInitializer::has_non_default_static_fields  should be has_default_static_fields

Reviewed-by: iklam

-------------

PR: https://git.openjdk.org/leyden/pull/22

From macarte at openjdk.org  Wed Sep 18 14:43:59 2024
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 18 Sep 2024 14:43:59 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v6]
In-Reply-To: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
Message-ID: <BUXMsc3Hw0Jk1O-7JSzVPm_NiquJYFQFbRQslAB-zZQ=.4ff63a7d-4d0b-4859-a4d9-010fcc312ec0@github.com>

> AOT training can be ended using either
> 
> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
> - jcmd <pid> AOT.end_training
> 
> supports arm64 and x64
> 
> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
> 
> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Added prolog variants for methods that trigger end of AOT training; removed redundent checks now the triggers only added to the flagged methods

-------------

Changes:
  - all: https://git.openjdk.org/leyden/pull/21/files
  - new: https://git.openjdk.org/leyden/pull/21/files/5241ca39..cf63f7f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=05
 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=04-05

  Stats: 174 lines in 17 files changed: 101 ins; 20 del; 53 mod
  Patch: https://git.openjdk.org/leyden/pull/21.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/21/head:pull/21

PR: https://git.openjdk.org/leyden/pull/21

From macarte at openjdk.org  Wed Sep 18 14:53:51 2024
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 18 Sep 2024 14:53:51 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v7]
In-Reply-To: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
Message-ID: <kKYfcAD4XfOFdkHeCm7I36TwSMb3Fnq-VKilLr1Q6LA=.1f1c3c47-9342-4ca5-a3e8-0c10da20e75e@github.com>

> AOT training can be ended using either
> 
> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
> - jcmd <pid> AOT.end_training
> 
> supports arm64 and x64
> 
> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
> 
> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  removed a single whitespace

-------------

Changes:
  - all: https://git.openjdk.org/leyden/pull/21/files
  - new: https://git.openjdk.org/leyden/pull/21/files/cf63f7f2..f9901e5e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=06
 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/leyden/pull/21.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/21/head:pull/21

PR: https://git.openjdk.org/leyden/pull/21

From macarte at openjdk.org  Wed Sep 18 14:53:51 2024
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 18 Sep 2024 14:53:51 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v5]
In-Reply-To: <o5nLJ9rBREcqmjM_6CuPLqt_laP0lgq3lHXMfq3KQK8=.417ac24d-a36d-405e-8b16-a73315bd2bb6@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
 <O62aA2NFpuIOziFFeYmSzfkY7ZkI3n127LHUK3ZyYlI=.822b9602-be51-4c78-b36d-8a4747d452f0@github.com>
 <o5nLJ9rBREcqmjM_6CuPLqt_laP0lgq3lHXMfq3KQK8=.417ac24d-a36d-405e-8b16-a73315bd2bb6@github.com>
Message-ID: <HE_6SfGXdpiQRNlvMMLTFT0cvjBvAMaQ9PJQD_hAiZ8=.ec737cab-2ebb-4e06-b644-04e1a0c79ff2@github.com>

On Tue, 17 Sep 2024 04:22:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed extra space left over from reverted change
>
> src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1280:
> 
>> 1278:   // AOT training run support
>> 1279:   __ end_training_check();
>> 1280: 
> 
> I wonder how much this will slow down the interpreter, as we trap into the VM on every interpreter entry. Could you do something like
> 
> 
> long start = System.currentTimeMillis();
> for (int i = 0; i < 10000000; i++) {
>     emptyMethod();
> }
> System.out.println(System.currentMillis() - start();
> 
> 
> and run it with something like this? 
> 
> 
> rm foo.cds
> java -Xint  -XX:+UnlockDiagnosticVMOptions -XX:+CDSManualFinalImage -XX:CacheDataStore=foo.cds ...

The latest commit changes how we add triggers to the interpreter.  I added variants for the prologs that can have triggers, so only flagged methods will trap in the VM.  Also as the triggers are now only in flagged methods the VM code is faster as it no longer has to wrangle the method handle to test the flags.  While the traps remain even after the end of training has been triggered, the early out tests reduce the performance impact

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/21#discussion_r1765205875

From asmehra at redhat.com  Wed Sep 18 16:10:30 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Wed, 18 Sep 2024 12:10:30 -0400
Subject: premain: Crash in Infinispan server code caused by NPE under
 MethodHandleNative::linkDynamicConstant
In-Reply-To: <0d22d580-39a1-4105-a50e-8a74a555090d@oracle.com>
References: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
 <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>
 <CAKt0pySztvwsadtrqjai6XwakAWq_v_o8men4aopLo4X-0azyQ@mail.gmail.com>
 <CAKt0pyQ44E+npyUW35Zhxg+PfBgF2yuNgS61gj1GGj=aLGTJXw@mail.gmail.com>
 <CAKt0pyT48uPH6rUL7bEJ2rtWqNdNL34DWBJ2SDaHwYfVxURnQw@mail.gmail.com>
 <0d22d580-39a1-4105-a50e-8a74a555090d@oracle.com>
Message-ID: <CAKt0pyRYBNtkLzVoAfDHWE=4e+9efZFb+xKYZv-d3LpDAU4qZg@mail.gmail.com>

Hi Ioi,

I was having a similar circularity issue (but in production time) and I
> just added enough classes to make the NPE go away.
>

I am wondering if you have a test case that reproduces the NPE which
prompted you to add these classes:

https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp#L65-L78

I commented this code and ran the tests under premain but didn't hit the
NPE.

Thanks,
- Ashutosh Mehra


On Tue, Sep 17, 2024 at 1:11?AM <ioi.lam at oracle.com> wrote:

> Hi Ashutosh,
>
> So this looks like a potential bug (or feature) in the core lib code. When
> CDS forcefully initializes a class in an unexpected (or untested) order,
> the "initialization soup" fails.
>
> Perhaps a work-around would be to make some harmless calls at the place
> where CDS was calling into MethodType.createArchivedObjects(). E.g., do
> something like this:
>
> +    if (CDSConfig::is_dumping_invokedynamic()) {
> +       // call into Java: jdk.internal.misc::warmupInvokeDynamic();
> +   }
>     // Rewrite and link classes
>     log_info(cds)("Rewriting and linking classes ...");
>
> Maybe you can add a new Lambda expressions, MethodHandle invocations, etc,
> that would hopefully cause PrimitiveClassDescImpl and friends to be
> initialized in their natural order.
>
> Or call class.forName("java.lang.constant.ConstantDescs") ??
>
> BTW, you can see my comments in
> AOTClassInitializer::is_forced_preinit_class():
>
>     // TODO:
>     // This is needed since JDK-8338532. Without this, when
>     // archived heap objects are used, the class init order is not
>     // expected by the jdk/internal/constant bootstrap code and we
>     // will get a null pointer exception.
>     //
>     // When bootstraping has intricated/fragile order, it's probably
>     // better to archive all related classes in an initialized state
>     // (i.e., take a snapshot). The existing approach in
>     // heapShared::resolve_or_init_classes_for_subgraph_of() won't work.
>     "jdk/internal/constant/PrimitiveClassDescImpl",
>     "jdk/internal/constant/ReferenceClassDescImpl",
>     "java/lang/constant/ConstantDescs",
>     "sun/invoke/util/Wrapper",
>
> I was having a similar circularity issue (but in production time) and I
> just added enough classes to make the NPE go away. For your test case, if
> you manage to fix in in the assembly run but run into NPE in production
> run, you might need to add more classes to this list. Yes, it's a hack :-(
>
>
> Thanks
>
> - Ioi
> On 9/13/24 7:05 PM, Ashutosh Mehra wrote:
>
> This is turning out to be a real example of class initialization soup!
> As mentioned during the meeting, I am getting NPE in the assembly phase
> when testing the patch [0] that I proposed in my earlier mail
> using a test case inspired by the Infinispan code.
> NPE occurs when running the class initializer for PrimitiveClassDescImpl
> Interestingly, PrimitiveClassDescImpl is "forcefully" initialized by
> MetaspaceShared::link_shared_classes().
>
> I couldn't get a stack trace so I relied on exception logs (using
> -Xlog:exceptions=trace) to find the cause which indicate following frames
> on the stack:
>
> [0]
> jdk/internal/constant/MethodTypeDescImpl::validateArgument(Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/ClassDesc; @
> bci 1
> [1]
> jdk/internal/constant/MethodTypeDescImpl::ofTrusted(Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljdk/internal/constant/MethodTypeDescImpl; @
> bci 27
> [2]
> java/lang/constant/ConstantDescs::ofConstantBootstrap(Ljava/lang/constant/ClassDesc;Ljava/lang/String;Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/DirectMethodHandleDesc; @
> bci 47
> [3] java/lang/constant/ConstantDescs::<clinit> @ bci 664
> [4]
> jdk/internal/constant/PrimitiveClassDescImpl::<init>(Ljava/lang/String;)V @
> bci 1
> [5]
> jdk/internal/constant/PrimitiveClassDescImpl::<clinit>(Ljava/lang/String;)V @
> bci 6
>
> Notice that invocation of PrimitiveClassDescImpl::<clinit> results in
> initialization of ConstantDescs class (see frame 3).
> ConstantDescs::<clinit> @ 664 corresponds to following java code:
>
>     public static final DirectMethodHandleDesc BSM_CLASS_DATA_AT
>             = ofConstantBootstrap(CD_MethodHandles, "classDataAt",
>             CD_Object, CD_int);
>
> The last parameter CD_int is initialized as:
>
>     public static final ClassDesc CD_int = PrimitiveClassDescImpl.CD_int;
>
> So, its value is obtained from PrimitiveClassDescImpl.CD_int which hasn't
> been initialized properly yet. As a result ConstantDescs::CD_int is
> assigned null which results in MethodTypeDescImpl::validateArgument
> throwing NPE later.
> There is a clear class initialization circularity involving
> PrimitiveClassDescImpl and ConstantDescs, and the result depends on which
> class gets initialized first.
>
> Without my patch this issue is not seen because PrimitiveClassDescImpl
> has already been initialized by the time
> MetaspaceShared::link_shared_classes() is called.
> Its initialization is triggered by the call to
> MethodType::createArchivedObjects().
> It also explains why my patch introduced this issue because it effectively
> moved the call to MethodType::createArchivedObjects() after
> MetaspaceShared::link_shared_classes().
>
> [0]
> https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>
> Thanks,
> - Ashutosh Mehra
>
>
> On Wed, Sep 11, 2024 at 3:12?PM Ashutosh Mehra <asmehra at redhat.com> wrote:
>
>> Regarding the WrongMethodTypeException that I mentioned in my previous
>> email (see pt 3),
>> this exception happens when lambda proxy class attempts to invoke the
>> MethodHandle it obtained from the classData:
>>
>>   public void accept(java.lang.Object);
>>     descriptor: (Ljava/lang/Object;)V
>>     flags: (0x0001) ACC_PUBLIC
>>     Code:
>>       stack=3, locals=2, args_size=2
>>          0: ldc           #26                 // Dynamic
>> #0:_:Ljava/lang/invoke/MethodHandle;
>>          2: aload_0
>>          3: getfield      #13                 // Field
>> arg$1:Lorg/wildfly/security/WildFlyElytronBaseProvider;
>>          6: aload_1
>>          7: checkcast     #28                 // class
>> java/security/Provider$Service
>>         10: invokevirtual #34                 // Method
>> java/lang/invoke/MethodHandle.invokeExact:(Lorg/wildfly/security/WildFlyElytronBaseProvider;Ljava/security/Provider$Service;)V
>>         13: return
>>
>> The scenario is during the assembly phase as part of the indy resolution
>> the MethodHandle for which the exception is thrown gets created.
>> Normally MethodHandle's type gets added in MethodType::internTable but
>> by the time indy resolution happens, JVM has already taken
>> snapshot of the MethodType::internTable through an upcall to
>> MethodType::createArchivedObjects().
>> As a result the AOTCache ends up with the MethodType object which is not
>> in AOTHolder.archivedMethodTypes.
>>
>> During the production run, when the jvm invokes the MethodHandle, it
>> searches for the MethodType corresponding to the signature passed at the
>> callsite.
>> As expected, it fails to find it in the AOTHolder.archivedMethodTypes,
>> so it creates a new instance of the MethodType.
>> But Invokers.checkExactType() relies on the MethodHandle's type to be
>> the same object as the MethodType object passed as parameter.
>>
>>     static void checkExactType(MethodHandle mhM, MethodType expected) {
>>         MethodType targetType = mh.type();
>>         if (targetType != expected)
>>             throw newWrongMethodTypeException(targetType, expected);
>>     }
>>
>> Hence, it throws WrongMethodTypeException though the two MT objects have
>> the same signature.
>>
>> To handle this scenario, I changed the order of indy resolution and upcall
>> to MethodType::createArchivedObjects() as:
>>
>> diff --git a/src/hotspot/share/cds/metaspaceShared.cpp
>> b/src/hotspot/share/cds/metaspaceShared.cpp
>> index df4bcadefa3..457716cac5b 100644
>> --- a/src/hotspot/share/cds/metaspaceShared.cpp
>> +++ b/src/hotspot/share/cds/metaspaceShared.cpp
>> @@ -751,6 +751,20 @@ void MetaspaceShared::link_shared_classes(bool
>> jcmd_request, TRAPS) {
>>    if (CDSConfig::is_dumping_final_static_archive()) {
>>      FinalImageRecipes::apply_recipes(CHECK);
>>    }
>> +
>> +#if INCLUDE_CDS_JAVA_HEAP
>> +  if (CDSConfig::is_dumping_invokedynamic()) {
>> +    // This makes sure that the MethodType and MethodTypeForm tables
>> won't be updated
>> +    // concurrently when we are saving their contents into a side table.
>> +    assert(CDSConfig::allow_only_single_java_thread(), "Required");
>> +
>> +    JavaValue result(T_VOID);
>> +    JavaCalls::call_static(&result, vmClasses::MethodType_klass(),
>> +                           vmSymbols::createArchivedObjects(),
>> +                           vmSymbols::void_method_signature(),
>> +                           CHECK);
>> +  }
>> +#endif
>>  }
>>
>> Note that indy resolution happens as part of FinalImageRecipes::apply_recipes(CHECK)
>> which is now invoked before the upcall to createArchivedObjects().
>> With this change I am able to run the application without any exceptions.
>> My complete patch can be seen here:
>> https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>> I will do more testing with this patch.
>>
>> @Ioi Lam <ioi.lam at oracle.com> do you have any feedback on this patch.
>>
>> Thanks,
>> - Ashutosh Mehra
>>
>>
>>
>> On Wed, Sep 11, 2024 at 10:14?AM Ashutosh Mehra <asmehra at redhat.com>
>> wrote:
>>
>>> Hi Andrew,
>>> Thanks for sharing the initial investigation.
>>> I have been looking into this and have a few of things to add to your
>>> analysis:
>>>
>>> 1.  As you mentioned the classData for the lambda
>>> class WildFlyElytronBaseProvider$$Lambda is null.
>>> The classData is stored in the mirror object of the InstanceKlass when
>>> the class is defined through JVM_LookupDefineClass.
>>> However, when we create the scratch mirror object (which get stored in
>>> the AOT cache) the classData is not populated.
>>> See
>>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp#L1128-L1131
>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp*L1128-L1131__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhbKjzG3gw$>
>>>
>>>   Handle classData; // set to null. Will be reinitialized at runtime
>>>   Handle mirror;
>>>   Handle comp_mirror;
>>>   allocate_mirror(k, /*is_scratch=*/true, protection_domain, classData,
>>> mirror, comp_mirror, CHECK);
>>>
>>> So this explains why the call to classData(caller.lookupClass())
>>> returned null.
>>>
>>> 2. In the mainline there is a check in InnerClassLambdaMetafactory.java
>>> for the particular code pattern used by the application.
>>> If this code pattern is found then the lambda proxy class is not
>>> included in the CDS archive.
>>> See
>>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L163-L170
>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L163-L170__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZl2S9tQg$>
>>> and
>>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L246
>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L246__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhYsI3Xx0g$>
>>>
>>>         // If the target class invokes a protected method inherited from
>>> a
>>>         // superclass in a different package, or does 'invokespecial',
>>> the
>>>         // lambda class has no access to the resolved method, or does
>>>         // 'invokestatic' on a hidden class which cannot be resolved by
>>> name.
>>>         // Instead, we need to pass the live implementation method
>>> handle to
>>>         // the proxy class to invoke directly. (javac prefers to avoid
>>> this
>>>         // situation by generating bridges in the target class)
>>>         useImplMethodHandle =
>>> (Modifier.isProtected(implInfo.getModifiers()) &&
>>>                                !VerifyAccess.isSamePackage(targetClass,
>>> implInfo.getDeclaringClass())) ||
>>>                                implKind ==
>>> MethodHandleInfo.REF_invokeSpecial ||
>>>                                implKind ==
>>> MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>>>
>>> In premain lambda proxy classes get included in the AOT cache as a
>>> result of indy resolution and that mechanism doesn't have this kind of
>>> check.
>>>
>>> 3. For the null classData problem mentioned above, I tried to fix it by
>>> storing classData in the scratch mirror using the following patch:
>>>
>>> diff --git a/src/hotspot/share/classfile/javaClasses.cpp
>>> b/src/hotspot/share/classfile/javaClasses.cpp
>>> index bd8141adbcc..41766e98093 100644
>>> --- a/src/hotspot/share/classfile/javaClasses.cpp
>>> +++ b/src/hotspot/share/classfile/javaClasses.cpp
>>> @@ -1094,9 +1094,9 @@ void java_lang_Class::create_mirror(Klass* k,
>>> Handle class_loader,
>>>      }
>>>      if (CDSConfig::is_dumping_heap()) {
>>>        if (CDSConfig::is_dumping_protection_domains()) {
>>> -        create_scratch_mirror(k, protection_domain, CHECK);
>>> +        create_scratch_mirror(k, protection_domain, classData, CHECK);
>>>        } else {
>>> -        create_scratch_mirror(k, Handle() /* null protection_domain*/,
>>> CHECK);
>>> +        create_scratch_mirror(k, Handle() /* null protection_domain*/,
>>> classData, CHECK);
>>>        }
>>>      }
>>>    } else {
>>> @@ -1117,7 +1117,7 @@ void java_lang_Class::create_mirror(Klass* k,
>>> Handle class_loader,
>>>  // Note: we archive the "scratch mirror" instead of k->java_mirror(),
>>> because the
>>>  // latter may contain dumptime-specific information that cannot be
>>> archived
>>>  // (e.g., ClassLoaderData*, or static fields that are modified by Java
>>> code execution).
>>> -void java_lang_Class::create_scratch_mirror(Klass* k, Handle
>>> protection_domain, TRAPS) {
>>> +void java_lang_Class::create_scratch_mirror(Klass* k, Handle
>>> protection_domain, Handle classData, TRAPS) {
>>>    if (k->class_loader() != nullptr &&
>>>        k->class_loader() != SystemDictionary::java_platform_loader() &&
>>>        k->class_loader() != SystemDictionary::java_system_loader()) {
>>> @@ -1125,9 +1125,11 @@ void
>>> java_lang_Class::create_scratch_mirror(Klass* k, Handle protection_domain,
>>>      return;
>>>    }
>>>
>>> -  Handle classData; // set to null. Will be reinitialized at runtime
>>> +  //Handle classData; // set to null. Will be reinitialized at runtime
>>>    Handle mirror;
>>>    Handle comp_mirror;
>>>    allocate_mirror(k, /*is_scratch=*/true, protection_domain, classData,
>>> mirror, comp_mirror, CHECK);
>>>
>>>    if (comp_mirror() != nullptr) {
>>> diff --git a/src/hotspot/share/classfile/javaClasses.hpp
>>> b/src/hotspot/share/classfile/javaClasses.hpp
>>> index bc49a0861a7..7ec2a2556dd 100644
>>> --- a/src/hotspot/share/classfile/javaClasses.hpp
>>> +++ b/src/hotspot/share/classfile/javaClasses.hpp
>>> @@ -263,7 +263,7 @@ class java_lang_Class : AllStatic {
>>>
>>>    // Archiving
>>>    static void serialize_offsets(SerializeClosure* f) NOT_CDS_RETURN;
>>> -  static void create_scratch_mirror(Klass* k, Handle protection_domain,
>>> TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>>> +  static void create_scratch_mirror(Klass* k, Handle protection_domain,
>>> Handle classData, TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>>>    static bool restore_archived_mirror(Klass *k, Handle class_loader,
>>> Handle module,
>>>                                        Handle protection_domain,
>>>                                        TRAPS)
>>> NOT_CDS_JAVA_HEAP_RETURN_(false);
>>>
>>> But this resulted in a different exception:
>>>
>>> Exception in thread "main" java.lang.ExceptionInInitializerError
>>> at com.redhat.leyden.Main.main(Main.java:7)
>>> Caused by: java.lang.invoke.WrongMethodTypeException: handle's method
>>> type (WildFlyElytronBaseProvider,Service)void but found
>>> (WildFlyElytronBaseProvider,Service)void
>>> at
>>> java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>>> at java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>>> at
>>> java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
>>> at
>>> org.wildfly.security.WildFlyElytronBaseProvider$$Lambda/0x80000000c.accept(Unknown
>>> Source)
>>> at
>>> org.wildfly.security.WildFlyElytronBaseProvider.putMakedPasswordImplementations(WildFlyElytronBaseProvider.java:112)
>>> at
>>> org.wildfly.security.WildFlyElytronBaseProvider.putPasswordImplementations(WildFlyElytronBaseProvider.java:107)
>>> at
>>> org.wildfly.security.password.WildFlyElytronPasswordProvider.<init>(WildFlyElytronPasswordProvider.java:43)
>>> at
>>> org.wildfly.security.password.WildFlyElytronPasswordProvider.<clinit>(WildFlyElytronPasswordProvider.java:36)
>>> ... 1 more
>>>
>>> The exception message is strange because the handle's method type and
>>> the expected type are both symbolically the same.
>>> I am debugging this exception at the moment.
>>>
>>> Thanks,
>>> - Ashutosh Mehra
>>>
>>>
>>> On Wed, Sep 11, 2024 at 6:03?AM Andrew Dinn <adinn at redhat.com> wrote:
>>>
>>>> Oops, sorry, I debugged this a few days ago! Correction to a few
>>>> details:
>>>>
>>>> On 11/09/2024 10:39, Andrew Dinn wrote:
>>>> > A crash due to an NPE was observed in the Infinispan (Data Grid)
>>>> server
>>>> > app when deployed using the Leyden EA. The crash still manifests with
>>>> > the latest premain code. The crash happens below an application call
>>>> > which employs a method reference as argument
>>>> >
>>>> >          putMakedPasswordImplementations(this::putService, this);
>>>>
>>>> The called method in turn calls consumer.accept
>>>>
>>>>              consumer.accept(new Service(provider,
>>>> PASSWORD_FACTORY_TYPE, algorithm,
>>>> "org.wildfly.security.password.impl.PasswordFactorySpiImpl", emptyList,
>>>> emptyMap));
>>>>
>>>> which enters enters MethodHandleNative::linkDynamicConstant()
>>>>
>>>> > Debugging shows that the call to linkDynamicConstant() returns null.
>>>> >
>>>> > A simple reproducer for the problem is available as a maven project
>>>> on
>>>> > github:
>>>> >
>>>> >    https://github.com/tristantarrant/elytron-leyden
>>>> <https://urldefense.com/v3/__https://github.com/tristantarrant/elytron-leyden__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZaZr1akQ$>
>>>> >
>>>> > The ReadMe provides an explanation of how to reproduce the problem. I
>>>> > did so and the debugged to find out some of the details of what is
>>>> > happening (see below) but did not fully clarify the problem. Help
>>>> from
>>>> > someone more conversant with the ins and outs of method handle
>>>> > bootstraps in premain would be welcome. Details follow.
>>>> >
>>>> > regards,
>>>> >
>>>> >
>>>> > Andrew Dinn
>>>> > -----------
>>>> >
>>>> > I downloaded the git repo and attached the Java sources using Maven
>>>> command
>>>> >
>>>> >    $ mvn dependency:sources
>>>> >
>>>> > Having manifested the crash by following the instructions in the
>>>> README
>>>> > I reran the leyden JVM under gdb using the following commands to
>>>> enable
>>>> > Java debugging
>>>> >
>>>> > $ gdb ${LEYDEN_HOME}/bin/java
>>>> > (gdb) cd /path/to/mvn/project
>>>> > (gdb) run
>>>> > -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
>>>> > -classpath
>>>> >
>>>> /home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/
>>>> 2.5.1.
>>>> <https://urldefense.com/v3/__http://2.5.1.__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhauJ-RjcQ$>Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar
>>>> -XX:CacheDataStore=elytron.aot com.redhat.leyden.Main
>>>> >
>>>> > The problem manifests at WildflyElytronBaseProvider.java:112 in
>>>> method
>>>> > WildflyElytronBaseProvider::putMakedPasswordImplementations
>>>>
>>>>      static void putMakedPasswordImplementations(Consumer<Service>
>>>> consumer, Provider provider) {
>>>>          for (String algorithm : MASKED_ALGORITHMS) {
>>>>              consumer.accept(new Service(provider,
>>>> PASSWORD_FACTORY_TYPE, algorithm,
>>>> "org.wildfly.security.password.impl.PasswordFactorySpiImpl", emptyList,
>>>> emptyMap)); <== NPE under this call
>>>>          }
>>>>
>>>>
>>>> > The source code for this method can be found in the following source
>>>> jar
>>>> >
>>>> >
>>>> >
>>>> ${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar
>>>> >
>>>> > (where M2_REPO will normally be ~/.m2/repository)
>>>> >
>>>> > Stepping into accept eventually enters
>>>> MethodHandleNative::linkDynamicConstant
>>>> > which in turn enters into ConstantBootstraps.makeConstant(). The
>>>> caller
>>>> > Class at this point is a lambda class which prints as
>>>> > org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c
>>>> >
>>>> > Several steps further the code enters BootstrapMethodInvoker::invoke
>>>> > (below the app method call but via 3 hidden frames) with
>>>> bootstrapMethod
>>>> > bound to a DirectMethodHandle. After several more steps this enters
>>>> > DirectMethodHandle$Holder.invokeStatic which in turn calls
>>>> > MethodHandles::classData(Lookup,String,Class).
>>>> >
>>>> > At this point caller is a MethodHandleLookup for the lambda class
>>>> > Lambda/0x800000000c mentioned above. The following call
>>>> >
>>>> >           Object classdata = classData(caller.lookupClass());
>>>> >
>>>> > returns null to DirectMethodHandle$Holder.invokeStatic which pops the
>>>> > same result back out to BootstrapMethodInvoker::invoke at line 90
>>>> >
>>>> >                  if (type instanceof Class<?> c) {
>>>> >                      result = bootstrapMethod.invoke(caller, name,
>>>> c);
>>>> > <== null
>>>> >
>>>> > This null result pops back out as the value for the call to
>>>> > BootstrapMethodInvoker.invoke(), ConstantBootstraps.makeConstant()
>>>> and
>>>> > MethodHandleNative::linkDynamicConstant().
>>>> >
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240918/fe4e2576/attachment.htm>

From asmehra at openjdk.org  Wed Sep 18 20:45:00 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 18 Sep 2024 20:45:00 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v7]
In-Reply-To: <kKYfcAD4XfOFdkHeCm7I36TwSMb3Fnq-VKilLr1Q6LA=.1f1c3c47-9342-4ca5-a3e8-0c10da20e75e@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
 <kKYfcAD4XfOFdkHeCm7I36TwSMb3Fnq-VKilLr1Q6LA=.1f1c3c47-9342-4ca5-a3e8-0c10da20e75e@github.com>
Message-ID: <LRWH_zUD2T2QQ8bKaxsNWrUIkHKpFpYs5WyLJhHN4Rg=.c5d396f1-64bf-4ed7-acab-3ba75ef44a13@github.com>

On Wed, 18 Sep 2024 14:53:51 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> AOT training can be ended using either
>> 
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
>> - jcmd <pid> AOT.end_training
>> 
>> supports arm64 and x64
>> 
>> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
>> 
>> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed a single whitespace

I think `is_end_training_trigger` needs to be cleared in `Method::remove_unshareable_flags()`. This flag should not be carried into the assembly phase if the Method is archived.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/21#issuecomment-2359367878

From macarte at openjdk.org  Wed Sep 18 23:21:25 2024
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 18 Sep 2024 23:21:25 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v8]
In-Reply-To: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
Message-ID: <0wA1S6VBenrXR_1lTxxdYoQNebe1l_Ns3t6R2xL5q4A=.b703dde8-da8c-4ea8-8b6d-593ffa57617c@github.com>

> AOT training can be ended using either
> 
> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
> - jcmd <pid> AOT.end_training
> 
> supports arm64 and x64
> 
> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
> 
> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Clear the method flags before committing to the archive, so that we don't require 'trigger' methods outside of training

-------------

Changes:
  - all: https://git.openjdk.org/leyden/pull/21/files
  - new: https://git.openjdk.org/leyden/pull/21/files/f9901e5e..d41acfcd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=07
 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=06-07

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/leyden/pull/21.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/21/head:pull/21

PR: https://git.openjdk.org/leyden/pull/21

From macarte at openjdk.org  Wed Sep 18 23:22:55 2024
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 18 Sep 2024 23:22:55 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v7]
In-Reply-To: <LRWH_zUD2T2QQ8bKaxsNWrUIkHKpFpYs5WyLJhHN4Rg=.c5d396f1-64bf-4ed7-acab-3ba75ef44a13@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
 <kKYfcAD4XfOFdkHeCm7I36TwSMb3Fnq-VKilLr1Q6LA=.1f1c3c47-9342-4ca5-a3e8-0c10da20e75e@github.com>
 <LRWH_zUD2T2QQ8bKaxsNWrUIkHKpFpYs5WyLJhHN4Rg=.c5d396f1-64bf-4ed7-acab-3ba75ef44a13@github.com>
Message-ID: <laKMbmdhG8aBTb77YZsMZYf9d3wS3L-rsM7c0T4r8wk=.57401520-61de-4ee8-be86-05a733d5e845@github.com>

On Wed, 18 Sep 2024 20:42:03 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> I think `is_end_training_trigger` needs to be cleared in `Method::remove_unshareable_flags()`. This flag should not be carried into the assembly phase if the Method is archived.

Thank you for the solution! I came across this problem while writing jtreg tests

-------------

PR Comment: https://git.openjdk.org/leyden/pull/21#issuecomment-2359614124

From macarte at openjdk.org  Thu Sep 19 02:24:42 2024
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 19 Sep 2024 02:24:42 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v9]
In-Reply-To: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
Message-ID: <u-mV8QEX6TlfZmz-t-yeFp7CJNjAQzyN9Qr_10NEu90=.778034a0-d6eb-44a8-8c8c-67a75cccff18@github.com>

> AOT training can be ended using either
> 
> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
> - jcmd <pid> AOT.end_training
> 
> supports arm64 and x64
> 
> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
> 
> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  jtreg tests for AOTEndTrainingOnMethodEntry

-------------

Changes:
  - all: https://git.openjdk.org/leyden/pull/21/files
  - new: https://git.openjdk.org/leyden/pull/21/files/d41acfcd..9f3a4c3c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=08
 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=07-08

  Stats: 191 lines in 1 file changed: 191 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/leyden/pull/21.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/21/head:pull/21

PR: https://git.openjdk.org/leyden/pull/21

From jrose at openjdk.org  Thu Sep 19 05:44:51 2024
From: jrose at openjdk.org (John R Rose)
Date: Thu, 19 Sep 2024 05:44:51 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v9]
In-Reply-To: <u-mV8QEX6TlfZmz-t-yeFp7CJNjAQzyN9Qr_10NEu90=.778034a0-d6eb-44a8-8c8c-67a75cccff18@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
 <u-mV8QEX6TlfZmz-t-yeFp7CJNjAQzyN9Qr_10NEu90=.778034a0-d6eb-44a8-8c8c-67a75cccff18@github.com>
Message-ID: <d6t_EWfaQsUBe4qMFAQiKZmHZjtfhyTKH0LUCiVL1-Y=.f9a80e0f-8525-4c1c-84e8-bb80237fe07b@github.com>

On Thu, 19 Sep 2024 02:24:42 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> AOT training can be ended using either
>> 
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
>> - jcmd <pid> AOT.end_training
>> 
>> supports arm64 and x64
>> 
>> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
>> 
>> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   jtreg tests for AOTEndTrainingOnMethodEntry

Suggestion:  Rename end_training_check in the interpreter to method_entry_upcall.  That way, the very wide but shallow changes to the assembly code will support a variety of features, not just this particular one.

Probably the same thing would work for the JITs as well.  So when C1 says


CDSConfig::is_dumping_preimage_static_archive_with_triggers() && callee->is_end_training_trigger()


Basically, the assembler and interpreter and JITs should not be thinking about CDS, just this newfangled "upcall".

it might as well say `callee->has_entry_upcall()` and the CDS-specific logic can be moved nearer to the method classes.  The name `is_end_training_trigger` can be retired or used in fewer places, when the only question at hand is whether to stick in an upcall.  Perhaps methodFlags continues to have `is_end_training_trigger` but `Method` exports `has_upcall` which delegates (internally) to `is_end_training_trigger`.

When you get to the C++ code for the upcall, just proceed as you do already, with a comment that the upcall has been installed if and only if the method was marked for training end.  Later on, that logic (again in C++) can be extended if we have other entry methods we wish to track.  Or not; maybe we'll never have a second use for this mechanism.  But even then, a more general looking name won't be harmful.  And there is some value in keeping the CDS-specific logic more localized, in a handful of functions that handle "upcalls" whatever those might be.

There are other lightweight versions of upcalls floating around too, low-level method entry notifications.  Some of them have been prototyped for Leyden (to trigger slow-burning recompilations from optimized code).  Factoring this feature into an upcall pattern might make it easier to merge the various kinds of upcalls into a common facility, eventually.

The name `_end_training_predicate` promises more than it is; shouldn't it be `_end_training_count_limit`?

I suggest passing the `CompileCommandEnum` into `parse_method_pattern`.  This will be a more user-facing instance of method patterns, so there will probably be special rules written for them.  Probably more restrictive than the present rules for method patterns in other compile commands.  For starters, we should choose between the dot-based and double-colon-based syntaxes.  I can't predict which way this conversation will go, but it will happen and we will be glad to be able to contextualize the parse to this particular command.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/21#issuecomment-2360024827

From ioi.lam at oracle.com  Thu Sep 19 05:45:20 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Wed, 18 Sep 2024 22:45:20 -0700
Subject: premain: Crash in Infinispan server code caused by NPE under
 MethodHandleNative::linkDynamicConstant
In-Reply-To: <CAKt0pyRYBNtkLzVoAfDHWE=4e+9efZFb+xKYZv-d3LpDAU4qZg@mail.gmail.com>
References: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
 <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>
 <CAKt0pySztvwsadtrqjai6XwakAWq_v_o8men4aopLo4X-0azyQ@mail.gmail.com>
 <CAKt0pyQ44E+npyUW35Zhxg+PfBgF2yuNgS61gj1GGj=aLGTJXw@mail.gmail.com>
 <CAKt0pyT48uPH6rUL7bEJ2rtWqNdNL34DWBJ2SDaHwYfVxURnQw@mail.gmail.com>
 <0d22d580-39a1-4105-a50e-8a74a555090d@oracle.com>
 <CAKt0pyRYBNtkLzVoAfDHWE=4e+9efZFb+xKYZv-d3LpDAU4qZg@mail.gmail.com>
Message-ID: <da797fe2-137c-4fc7-a67c-3b595c0c63f2@oracle.com>

Hi Ashutosh,

I have some update:

The original crash was caused by the "useImplMethodHandle" code in 
InnerClassLambdaMetafactory.java:

 ??????? // If the target class invokes a protected method inherited from a
 ??????? // superclass in a different package, or does 'invokespecial', the
 ??????? // lambda class has no access to the resolved method, or does
 ??????? // 'invokestatic' on a hidden class which cannot be resolved by 
name.
 ??????? // Instead, we need to pass the live implementation method 
handle to
 ??????? // the proxy class to invoke directly. (javac prefers to avoid this
 ??????? // situation by generating bridges in the target class)
 ??????? useImplMethodHandle = 
(Modifier.isProtected(implInfo.getModifiers()) &&
!VerifyAccess.isSamePackage(targetClass, implInfo.getDeclaringClass())) ||
 ?????????????????????????????? implKind == 
MethodHandleInfo.REF_invokeSpecial ||
 ?????????????????????????????? implKind == 
MethodHandleInfo.REF_invokeStatic && implClass.isHidden();

As I am cleaning up the code for upstreaming to mainline, I am going add 
an equivalent check in the C code to filter out these indy call sites, 
so they won't be resolved at all during the assembly phase. Otherwise, I 
will run into problems described in 
https://bugs.openjdk.org/browse/JDK-8290417

Once I get the filtering code working, I will integrate it back to premain.

 >I am wondering if we can workaround class circularity issues by 
recording class initialization order
 >during training run and use that to guide the initialization during 
assembly phase.

In the production run we take different paths than the training run

(1) some classes are aot-initialized (especially the enums)
(2) some classes make special CDS calls

so I am not sure if it's possible to get the same initialization order 
as in the training run (or assembly phase).

(more below)

On 9/18/24 9:10 AM, Ashutosh Mehra wrote:
> Hi Ioi,
>
>     I was having a similar circularity issue (but in production time)
>     and I just added enough classes to make the NPE go away.
>
> I am wondering if you have a test case that reproduces the NPE which 
> prompted you to add these classes:
>
> https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp#L65-L78 
> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp*L65-L78__;Iw!!ACWV5N9M2RV99hQ!NYvqLbb_Ib2kSdm2fcYVLGby-AiB2TG7KtC1HQHVKLiM-_kRb5mOt8krV5IZfReaYZ0MPadDfa08hQ$>
>
> I commented this code and ran the tests under premain but didn't 
> hit?the NPE.
>
I forgot what the problem was, but it happened for very simple cases.

Thanks

- Ioi


> Thanks,
> - Ashutosh Mehra
>
>
> On Tue, Sep 17, 2024 at 1:11?AM <ioi.lam at oracle.com> wrote:
>
>     Hi Ashutosh,
>
>     So this looks like a potential bug (or feature) in the core lib
>     code. When CDS forcefully initializes a class in an unexpected (or
>     untested) order, the "initialization soup" fails.
>
>     Perhaps a work-around would be to make some harmless calls at the
>     place where CDS was calling into
>     MethodType.createArchivedObjects(). E.g., do something like this:
>
>     +??? if (CDSConfig::is_dumping_invokedynamic()) {
>     +?????? // call into Java: jdk.internal.misc::warmupInvokeDynamic();
>     +?? }
>     ??? // Rewrite and link classes
>     ??? log_info(cds)("Rewriting and linking classes ...");
>
>     Maybe you can add a new Lambda expressions, MethodHandle
>     invocations, etc, that would hopefully cause
>     PrimitiveClassDescImpl and friends to be initialized in their
>     natural order.
>
>     Or call class.forName("java.lang.constant.ConstantDescs") ??
>
>     BTW, you can see my comments in
>     AOTClassInitializer::is_forced_preinit_class():
>
>     ??? // TODO:
>     ??? // This is needed since JDK-8338532. Without this, when
>     ??? // archived heap objects are used, the class init order is not
>     ??? // expected by the jdk/internal/constant bootstrap code and we
>     ??? // will get a null pointer exception.
>     ??? //
>     ??? // When bootstraping has intricated/fragile order, it's probably
>     ??? // better to archive all related classes in an initialized state
>     ??? // (i.e., take a snapshot). The existing approach in
>     ??? // heapShared::resolve_or_init_classes_for_subgraph_of() won't
>     work.
>     ??? "jdk/internal/constant/PrimitiveClassDescImpl",
>     ??? "jdk/internal/constant/ReferenceClassDescImpl",
>     ??? "java/lang/constant/ConstantDescs",
>     ??? "sun/invoke/util/Wrapper",
>
>     I was having a similar circularity issue (but in production time)
>     and I just added enough classes to make the NPE go away. For your
>     test case, if you manage to fix in in the assembly run but run
>     into NPE in production run, you might need to add more classes to
>     this list. Yes, it's a hack :-(
>
>
>     Thanks
>
>     - Ioi
>
>     On 9/13/24 7:05 PM, Ashutosh Mehra wrote:
>>     This is turning out to be a real example of class initialization
>>     soup!
>>     As mentioned during the meeting, I am getting NPE in the assembly
>>     phase when testing the patch [0] that I proposed in my earlier mail
>>     using a test case inspired by the Infinispan code.
>>     NPE occurs when running the class initializer for
>>     PrimitiveClassDescImpl
>>     Interestingly, PrimitiveClassDescImpl?is "forcefully" initialized
>>     by MetaspaceShared::link_shared_classes().
>>
>>     I couldn't get a stack trace so I relied on exception logs (using
>>     -Xlog:exceptions=trace) to find the cause which indicate
>>     following frames on the stack:
>>
>>     [0]
>>     jdk/internal/constant/MethodTypeDescImpl::validateArgument(Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/ClassDesc;?@
>>     bci 1
>>     [1]
>>     jdk/internal/constant/MethodTypeDescImpl::ofTrusted(Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljdk/internal/constant/MethodTypeDescImpl;?@
>>     bci 27
>>     [2]
>>     java/lang/constant/ConstantDescs::ofConstantBootstrap(Ljava/lang/constant/ClassDesc;Ljava/lang/String;Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/DirectMethodHandleDesc;?@
>>     bci 47
>>     [3] java/lang/constant/ConstantDescs::<clinit>?@ bci 664
>>     [4]
>>     jdk/internal/constant/PrimitiveClassDescImpl::<init>(Ljava/lang/String;)V?@
>>     bci 1
>>     [5]
>>     jdk/internal/constant/PrimitiveClassDescImpl::<clinit>(Ljava/lang/String;)V?@
>>     bci 6
>>
>>     Notice?that invocation of PrimitiveClassDescImpl::<clinit>
>>     results in initialization of ConstantDescs?class (see frame 3).
>>     ConstantDescs::<clinit>?@ 664 corresponds to following java code:
>>
>>     ? ? public static final DirectMethodHandleDesc BSM_CLASS_DATA_AT
>>     ? ? ? ? ? ? = ofConstantBootstrap(CD_MethodHandles, "classDataAt",
>>     ? ? ? ? ? ? CD_Object, CD_int);
>>
>>     The last parameter CD_int is initialized as:
>>
>>     ? ? public static final ClassDesc CD_int =
>>     PrimitiveClassDescImpl.CD_int;
>>
>>     So, its value is obtained from
>>     PrimitiveClassDescImpl.CD_int?which hasn't been initialized
>>     properly yet. As a result ConstantDescs::CD_int is assigned?null
>>     which results in MethodTypeDescImpl::validateArgument throwing
>>     NPE later.
>>     There is a clear class initialization circularity involving
>>     PrimitiveClassDescImpl and ConstantDescs, and the result depends
>>     on which class gets initialized first.
>>
>>     Without my patch this issue is not seen because
>>     PrimitiveClassDescImpl has already been initialized by the time
>>     MetaspaceShared::link_shared_classes()?is called.
>>     Its initialization is triggered by the call to
>>     MethodType::createArchivedObjects().
>>     It also explains why my patch introduced this issue because it
>>     effectively moved the call to MethodType::createArchivedObjects()
>>     after MetaspaceShared::link_shared_classes().
>>
>>     [0]
>>     https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>     <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>
>>     Thanks,
>>     - Ashutosh Mehra
>>
>>
>>     On Wed, Sep 11, 2024 at 3:12?PM Ashutosh Mehra
>>     <asmehra at redhat.com> wrote:
>>
>>         Regarding the WrongMethodTypeException that I mentioned in my
>>         previous email (see pt 3),
>>         this exception happens when lambda proxy class attempts to
>>         invoke the MethodHandle it obtained from the classData:
>>
>>         ? public void accept(java.lang.Object);
>>         ? ? descriptor: (Ljava/lang/Object;)V
>>         ? ? flags: (0x0001) ACC_PUBLIC
>>         ? ? Code:
>>         ? ? ? stack=3, locals=2, args_size=2
>>         ? ? ? ? ?0: ldc ? ? ? ? ? #26 ? ? ? ? ? ? ? ? // Dynamic
>>         #0:_:Ljava/lang/invoke/MethodHandle;
>>         ? ? ? ? ?2: aload_0
>>         ? ? ? ? ?3: getfield ? ? ?#13 ? ? ? ? ? ? ? ? // Field
>>         arg$1:Lorg/wildfly/security/WildFlyElytronBaseProvider;
>>         ? ? ? ? ?6: aload_1
>>         ? ? ? ? ?7: checkcast ? ? #28 ? ? ? ? ? ? ? ? // class
>>         java/security/Provider$Service
>>         ? ? ? ? 10: invokevirtual #34 ? ? ? ? ? ? ? ? // Method
>>         java/lang/invoke/MethodHandle.invokeExact:(Lorg/wildfly/security/WildFlyElytronBaseProvider;Ljava/security/Provider$Service;)V
>>         ? ? ? ? 13: return
>>
>>         The scenario is during the assembly phase as part of the indy
>>         resolution the MethodHandle for which the exception is thrown
>>         gets created.
>>         Normally MethodHandle's type gets added in
>>         MethodType::internTable but by the time indy resolution
>>         happens, JVM has already taken
>>         snapshot of the MethodType::internTable through an upcall to
>>         MethodType::createArchivedObjects().
>>         As a result the AOTCache ends up with the MethodType object
>>         which is not in AOTHolder.archivedMethodTypes.
>>
>>         During the production run, when the jvm invokes the
>>         MethodHandle, it searches for the MethodType corresponding to
>>         the signature passed at the callsite.
>>         As expected, it fails to find it in the
>>         AOTHolder.archivedMethodTypes, so it creates a new instance
>>         of the MethodType.
>>         But Invokers.checkExactType() relies on the
>>         MethodHandle's?type to be the same object as the MethodType
>>         object passed as parameter.
>>
>>         ? ? static void checkExactType(MethodHandle mhM, MethodType
>>         expected) {
>>         ? ? ? ? MethodType targetType = mh.type();
>>         ? ? ? ? if (targetType != expected)
>>         ? ? ? ? ? ? throw newWrongMethodTypeException(targetType,
>>         expected);
>>         ? ? }
>>
>>         Hence, it throws WrongMethodTypeException?though the two MT
>>         objects have the same signature.
>>
>>         To handle this scenario, I changed the order of indy
>>         resolution and upcall to MethodType::createArchivedObjects()?as:
>>
>>         diff --git a/src/hotspot/share/cds/metaspaceShared.cpp
>>         b/src/hotspot/share/cds/metaspaceShared.cpp
>>         index df4bcadefa3..457716cac5b 100644
>>         --- a/src/hotspot/share/cds/metaspaceShared.cpp
>>         +++ b/src/hotspot/share/cds/metaspaceShared.cpp
>>         @@ -751,6 +751,20 @@ void
>>         MetaspaceShared::link_shared_classes(bool jcmd_request, TRAPS) {
>>         ? ?if (CDSConfig::is_dumping_final_static_archive()) {
>>         ? ? ?FinalImageRecipes::apply_recipes(CHECK);
>>         ? ?}
>>         +
>>         +#if INCLUDE_CDS_JAVA_HEAP
>>         + ?if (CDSConfig::is_dumping_invokedynamic()) {
>>         + ? ?// This makes sure that the MethodType and
>>         MethodTypeForm tables won't be updated
>>         + ? ?// concurrently when we are saving their contents into a
>>         side table.
>>         + ?assert(CDSConfig::allow_only_single_java_thread(),
>>         "Required");
>>         +
>>         + ? ?JavaValue result(T_VOID);
>>         + ? ?JavaCalls::call_static(&result,
>>         vmClasses::MethodType_klass(),
>>         + vmSymbols::createArchivedObjects(),
>>         + vmSymbols::void_method_signature(),
>>         + ? ? ? ? ? ? ? ? ? ? ? ? ? CHECK);
>>         + ?}
>>         +#endif
>>         ?}
>>         Note that indy resolution happens as part of
>>         FinalImageRecipes::apply_recipes(CHECK) which is now invoked
>>         before the upcall to createArchivedObjects().
>>         With this change I am able to run the application without any
>>         exceptions.
>>         My complete patch can be seen here:
>>         https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>         <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>         I will do more testing with this patch.
>>
>>         @Ioi Lam <mailto:ioi.lam at oracle.com>?do you have any feedback
>>         on this patch.
>>
>>         Thanks,
>>         - Ashutosh Mehra
>>
>>
>>
>>         On Wed, Sep 11, 2024 at 10:14?AM Ashutosh Mehra
>>         <asmehra at redhat.com> wrote:
>>
>>             Hi Andrew,
>>             Thanks for sharing the initial investigation.
>>             I have been looking into this and have a few of things to
>>             add to your analysis:
>>
>>             1.? As you mentioned the classData for the lambda
>>             class?WildFlyElytronBaseProvider$$Lambda is null.
>>             The classData is stored in the mirror object of the
>>             InstanceKlass when the class is defined
>>             through?JVM_LookupDefineClass.
>>             However, when we create the scratch mirror object (which
>>             get stored in the AOT cache) the classData is not populated.
>>             See
>>             https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp#L1128-L1131
>>             <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp*L1128-L1131__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhbKjzG3gw$>
>>
>>             ? Handle classData; // set to null. Will be reinitialized
>>             at runtime
>>             ? Handle mirror;
>>             ? Handle comp_mirror;
>>             ? allocate_mirror(k, /*is_scratch=*/true,
>>             protection_domain, classData, mirror, comp_mirror, CHECK);
>>
>>             So this explains why the call to
>>             classData(caller.lookupClass())returned null.
>>
>>             2. In the mainline there is a check
>>             in?InnerClassLambdaMetafactory.java for the particular
>>             code pattern used by the application.
>>             If this code pattern is found then the lambda proxy class
>>             is not included in the CDS archive.
>>             See
>>             https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L163-L170
>>             <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L163-L170__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZl2S9tQg$>
>>             and
>>             https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L246
>>             <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L246__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhYsI3Xx0g$>
>>
>>             ? ? ? ? // If the target class invokes a protected method
>>             inherited from a
>>             ? ? ? ? // superclass in a different package, or does
>>             'invokespecial', the
>>             ? ? ? ? // lambda class has no access to the resolved
>>             method, or does
>>             ? ? ? ? // 'invokestatic' on a hidden class which cannot
>>             be resolved by name.
>>             ? ? ? ? // Instead, we need to pass the live
>>             implementation method handle to
>>             ? ? ? ? // the proxy class to invoke directly. (javac
>>             prefers to avoid this
>>             ? ? ? ? // situation by generating bridges in the target
>>             class)
>>             ? ? ? ? useImplMethodHandle =
>>             (Modifier.isProtected(implInfo.getModifiers()) &&
>>             ?!VerifyAccess.isSamePackage(targetClass,
>>             implInfo.getDeclaringClass())) ||
>>             ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?implKind ==
>>             MethodHandleInfo.REF_invokeSpecial ||
>>             ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?implKind ==
>>             MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>>
>>             In premain lambda proxy classes get included in the AOT
>>             cache as a result of indy resolution and that mechanism
>>             doesn't have this kind of check.
>>
>>             3. For the null classData problem mentioned above, I
>>             tried to fix it by storing classData in the scratch
>>             mirror using the following patch:
>>
>>             diff --git a/src/hotspot/share/classfile/javaClasses.cpp
>>             b/src/hotspot/share/classfile/javaClasses.cpp
>>             index bd8141adbcc..41766e98093 100644
>>             --- a/src/hotspot/share/classfile/javaClasses.cpp
>>             +++ b/src/hotspot/share/classfile/javaClasses.cpp
>>             @@ -1094,9 +1094,9 @@ void
>>             java_lang_Class::create_mirror(Klass* k, Handle class_loader,
>>             ? ? ?}
>>             ? ? ?if (CDSConfig::is_dumping_heap()) {
>>             ? ? ? ?if (CDSConfig::is_dumping_protection_domains()) {
>>             - ? ? ? ?create_scratch_mirror(k, protection_domain, CHECK);
>>             + ? ? ? ?create_scratch_mirror(k, protection_domain,
>>             classData, CHECK);
>>             ? ? ? ?} else {
>>             - ? ? ? ?create_scratch_mirror(k, Handle() /* null
>>             protection_domain*/, CHECK);
>>             + ? ? ? ?create_scratch_mirror(k, Handle() /* null
>>             protection_domain*/, classData, CHECK);
>>             ? ? ? ?}
>>             ? ? ?}
>>             ? ?} else {
>>             @@ -1117,7 +1117,7 @@ void
>>             java_lang_Class::create_mirror(Klass* k, Handle class_loader,
>>             ?// Note: we archive the "scratch mirror" instead of
>>             k->java_mirror(), because the
>>             ?// latter may contain dumptime-specific information that
>>             cannot be archived
>>             ?// (e.g., ClassLoaderData*, or static fields that are
>>             modified by Java code execution).
>>             -void java_lang_Class::create_scratch_mirror(Klass* k,
>>             Handle protection_domain, TRAPS) {
>>             +void java_lang_Class::create_scratch_mirror(Klass* k,
>>             Handle protection_domain, Handle classData, TRAPS) {
>>             ? ?if (k->class_loader() != nullptr &&
>>             ? ? ? ?k->class_loader() !=
>>             SystemDictionary::java_platform_loader() &&
>>             ? ? ? ?k->class_loader() !=
>>             SystemDictionary::java_system_loader()) {
>>             @@ -1125,9 +1125,11 @@ void
>>             java_lang_Class::create_scratch_mirror(Klass* k, Handle
>>             protection_domain,
>>             ? ? ?return;
>>             ? ?}
>>
>>             - ?Handle classData; // set to null. Will be
>>             reinitialized at runtime
>>             + ?//Handle classData; // set to null. Will be
>>             reinitialized at runtime
>>             ? ?Handle mirror;
>>             ? ?Handle comp_mirror;
>>             ? ?allocate_mirror(k, /*is_scratch=*/true,
>>             protection_domain, classData, mirror, comp_mirror, CHECK);
>>
>>             ? ?if (comp_mirror() != nullptr) {
>>             diff --git a/src/hotspot/share/classfile/javaClasses.hpp
>>             b/src/hotspot/share/classfile/javaClasses.hpp
>>             index bc49a0861a7..7ec2a2556dd 100644
>>             --- a/src/hotspot/share/classfile/javaClasses.hpp
>>             +++ b/src/hotspot/share/classfile/javaClasses.hpp
>>             @@ -263,7 +263,7 @@ class java_lang_Class : AllStatic {
>>
>>             ? ?// Archiving
>>             ? ?static void serialize_offsets(SerializeClosure* f)
>>             NOT_CDS_RETURN;
>>             - ?static void create_scratch_mirror(Klass* k, Handle
>>             protection_domain, TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>>             + ?static void create_scratch_mirror(Klass* k, Handle
>>             protection_domain, Handle classData, TRAPS)
>>             NOT_CDS_JAVA_HEAP_RETURN;
>>             ? ?static bool restore_archived_mirror(Klass *k, Handle
>>             class_loader, Handle module,
>>             ?Handle protection_domain,
>>             ?TRAPS) NOT_CDS_JAVA_HEAP_RETURN_(false);
>>
>>             But this resulted in a different exception:
>>
>>             Exception in thread "main"
>>             java.lang.ExceptionInInitializerError
>>             at com.redhat.leyden.Main.main(Main.java:7)
>>             Caused by: java.lang.invoke.WrongMethodTypeException:
>>             handle's method type
>>             (WildFlyElytronBaseProvider,Service)void but found
>>             (WildFlyElytronBaseProvider,Service)void
>>             at
>>             java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>>             at
>>             java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>>             at
>>             java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
>>             at
>>             org.wildfly.security.WildFlyElytronBaseProvider$$Lambda/0x80000000c.accept(Unknown
>>             Source)
>>             at
>>             org.wildfly.security.WildFlyElytronBaseProvider.putMakedPasswordImplementations(WildFlyElytronBaseProvider.java:112)
>>             at
>>             org.wildfly.security.WildFlyElytronBaseProvider.putPasswordImplementations(WildFlyElytronBaseProvider.java:107)
>>             at
>>             org.wildfly.security.password.WildFlyElytronPasswordProvider.<init>(WildFlyElytronPasswordProvider.java:43)
>>             at
>>             org.wildfly.security.password.WildFlyElytronPasswordProvider.<clinit>(WildFlyElytronPasswordProvider.java:36)
>>             ... 1 more
>>
>>             The exception message is strange because the handle's
>>             method type and the expected type are both symbolically
>>             the same.
>>             I am debugging this exception at the moment.
>>             Thanks,
>>             - Ashutosh Mehra
>>
>>
>>             On Wed, Sep 11, 2024 at 6:03?AM Andrew Dinn
>>             <adinn at redhat.com> wrote:
>>
>>                 Oops, sorry, I debugged this a few days ago!
>>                 Correction to a few details:
>>
>>                 On 11/09/2024 10:39, Andrew Dinn wrote:
>>                 > A crash due to an NPE was observed in the
>>                 Infinispan (Data Grid) server
>>                 > app when deployed using the Leyden EA. The crash
>>                 still manifests with
>>                 > the latest premain code. The crash happens below an
>>                 application call
>>                 > which employs a method reference as argument
>>                 >
>>                 > putMakedPasswordImplementations(this::putService,
>>                 this);
>>
>>                 The called method in turn calls consumer.accept
>>
>>                 ? ? ? ? ? ? ?consumer.accept(new Service(provider,
>>                 PASSWORD_FACTORY_TYPE, algorithm,
>>                 "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>                 emptyList,
>>                 emptyMap));
>>
>>                 which enters enters
>>                 MethodHandleNative::linkDynamicConstant()
>>
>>                 > Debugging shows that the call to
>>                 linkDynamicConstant() returns null.
>>                 >
>>                 > A simple reproducer for the problem is available as
>>                 a maven project on
>>                 > github:
>>                 >
>>                 > https://github.com/tristantarrant/elytron-leyden
>>                 <https://urldefense.com/v3/__https://github.com/tristantarrant/elytron-leyden__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZaZr1akQ$>
>>                 >
>>                 > The ReadMe provides an explanation of how to
>>                 reproduce the problem. I
>>                 > did so and the debugged to find out some of the
>>                 details of what is
>>                 > happening (see below) but did not fully clarify the
>>                 problem. Help from
>>                 > someone more conversant with the ins and outs of
>>                 method handle
>>                 > bootstraps in premain would be welcome. Details follow.
>>                 >
>>                 > regards,
>>                 >
>>                 >
>>                 > Andrew Dinn
>>                 > -----------
>>                 >
>>                 > I downloaded the git repo and attached the Java
>>                 sources using Maven command
>>                 >
>>                 >? ? $ mvn dependency:sources
>>                 >
>>                 > Having manifested the crash by following the
>>                 instructions in the README
>>                 > I reran the leyden JVM under gdb using the
>>                 following commands to enable
>>                 > Java debugging
>>                 >
>>                 > $ gdb ${LEYDEN_HOME}/bin/java
>>                 > (gdb) cd /path/to/mvn/project
>>                 > (gdb) run
>>                 >
>>                 -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
>>
>>                 > -classpath
>>                 >
>>                 /home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/2.5.1.
>>                 <https://urldefense.com/v3/__http://2.5.1.__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhauJ-RjcQ$>Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar
>>                 -XX:CacheDataStore=elytron.aot com.redhat.leyden.Main
>>                 >
>>                 > The problem manifests at
>>                 WildflyElytronBaseProvider.java:112 in method
>>                 >
>>                 WildflyElytronBaseProvider::putMakedPasswordImplementations
>>
>>                 ? ? ?static void
>>                 putMakedPasswordImplementations(Consumer<Service>
>>                 consumer, Provider provider) {
>>                 ? ? ? ? ?for (String algorithm : MASKED_ALGORITHMS) {
>>                 ? ? ? ? ? ? ?consumer.accept(new Service(provider,
>>                 PASSWORD_FACTORY_TYPE, algorithm,
>>                 "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>                 emptyList,
>>                 emptyMap)); <== NPE under this call
>>                 ? ? ? ? ?}
>>
>>
>>                 > The source code for this method can be found in the
>>                 following source jar
>>                 >
>>                 >
>>                 >
>>                 ${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar
>>                 >
>>                 > (where M2_REPO will normally be ~/.m2/repository)
>>                 >
>>                 > Stepping into accept eventually enters
>>                 MethodHandleNative::linkDynamicConstant
>>                 > which in turn enters into
>>                 ConstantBootstraps.makeConstant(). The caller
>>                 > Class at this point is a lambda class which prints as
>>                 >
>>                 org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c
>>                 >
>>                 > Several steps further the code enters
>>                 BootstrapMethodInvoker::invoke
>>                 > (below the app method call but via 3 hidden frames)
>>                 with bootstrapMethod
>>                 > bound to a DirectMethodHandle. After several more
>>                 steps this enters
>>                 > DirectMethodHandle$Holder.invokeStatic which in
>>                 turn calls
>>                 > MethodHandles::classData(Lookup,String,Class).
>>                 >
>>                 > At this point caller is a MethodHandleLookup for
>>                 the lambda class
>>                 > Lambda/0x800000000c mentioned above. The following call
>>                 >
>>                 >? ???????? Object classdata =
>>                 classData(caller.lookupClass());
>>                 >
>>                 > returns null to
>>                 DirectMethodHandle$Holder.invokeStatic which pops the
>>                 > same result back out to
>>                 BootstrapMethodInvoker::invoke at line 90
>>                 >
>>                 >? ??????????????? if (type instanceof Class<?> c) {
>>                 >? ??????????????????? result =
>>                 bootstrapMethod.invoke(caller, name, c);
>>                 > <== null
>>                 >
>>                 > This null result pops back out as the value for the
>>                 call to
>>                 > BootstrapMethodInvoker.invoke(),
>>                 ConstantBootstraps.makeConstant() and
>>                 > MethodHandleNative::linkDynamicConstant().
>>                 >
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240918/e1d22d05/attachment.htm>

From asmehra at redhat.com  Thu Sep 19 14:44:52 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Thu, 19 Sep 2024 10:44:52 -0400
Subject: premain: Crash in Infinispan server code caused by NPE under
 MethodHandleNative::linkDynamicConstant
In-Reply-To: <da797fe2-137c-4fc7-a67c-3b595c0c63f2@oracle.com>
References: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
 <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>
 <CAKt0pySztvwsadtrqjai6XwakAWq_v_o8men4aopLo4X-0azyQ@mail.gmail.com>
 <CAKt0pyQ44E+npyUW35Zhxg+PfBgF2yuNgS61gj1GGj=aLGTJXw@mail.gmail.com>
 <CAKt0pyT48uPH6rUL7bEJ2rtWqNdNL34DWBJ2SDaHwYfVxURnQw@mail.gmail.com>
 <0d22d580-39a1-4105-a50e-8a74a555090d@oracle.com>
 <CAKt0pyRYBNtkLzVoAfDHWE=4e+9efZFb+xKYZv-d3LpDAU4qZg@mail.gmail.com>
 <da797fe2-137c-4fc7-a67c-3b595c0c63f2@oracle.com>
Message-ID: <CAKt0pyRj8_mDiH58v10sqXNHA4iHja6-7D9N_S2VW9rhESPcTw@mail.gmail.com>

>
> As I am cleaning up the code for upstreaming to mainline, I am going add
> an equivalent check in the C code to filter out these indy call sites, so
> they won't be resolved at all during the assembly phase. Otherwise, I will
> run into problems described in https://bugs.openjdk.org/browse/JDK-8290417


Thanks for the link to the bug. The scenario described in that bug is
exactly the same as the Infinispan case.
So if we filter out such cases during indy resolution then it should
resolve the Infinispan issue as well.

A basic question: why can't CDS handle the lambda proxy class generated in
useImplMethodHandle mode?

Thanks,
- Ashutosh Mehra


On Thu, Sep 19, 2024 at 1:45?AM <ioi.lam at oracle.com> wrote:

> Hi Ashutosh,
>
> I have some update:
>
> The original crash was caused by the "useImplMethodHandle" code in
> InnerClassLambdaMetafactory.java:
>
>         // If the target class invokes a protected method inherited from a
>         // superclass in a different package, or does 'invokespecial', the
>         // lambda class has no access to the resolved method, or does
>         // 'invokestatic' on a hidden class which cannot be resolved by
> name.
>         // Instead, we need to pass the live implementation method handle
> to
>         // the proxy class to invoke directly. (javac prefers to avoid this
>         // situation by generating bridges in the target class)
>         useImplMethodHandle =
> (Modifier.isProtected(implInfo.getModifiers()) &&
>                                !VerifyAccess.isSamePackage(targetClass,
> implInfo.getDeclaringClass())) ||
>                                implKind ==
> MethodHandleInfo.REF_invokeSpecial ||
>                                implKind ==
> MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>
> As I am cleaning up the code for upstreaming to mainline, I am going add
> an equivalent check in the C code to filter out these indy call sites, so
> they won't be resolved at all during the assembly phase. Otherwise, I will
> run into problems described in https://bugs.openjdk.org/browse/JDK-8290417
>
> Once I get the filtering code working, I will integrate it back to premain.
>
> >I am wondering if we can workaround class circularity issues by recording
> class initialization order
> >during training run and use that to guide the initialization during
> assembly phase.
>
> In the production run we take different paths than the training run
>
> (1) some classes are aot-initialized (especially the enums)
> (2) some classes make special CDS calls
>
> so I am not sure if it's possible to get the same initialization order as
> in the training run (or assembly phase).
>
> (more below)
> On 9/18/24 9:10 AM, Ashutosh Mehra wrote:
>
> Hi Ioi,
>
> I was having a similar circularity issue (but in production time) and I
>> just added enough classes to make the NPE go away.
>>
>
> I am wondering if you have a test case that reproduces the NPE which
> prompted you to add these classes:
>
>
> https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp#L65-L78
> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp*L65-L78__;Iw!!ACWV5N9M2RV99hQ!NYvqLbb_Ib2kSdm2fcYVLGby-AiB2TG7KtC1HQHVKLiM-_kRb5mOt8krV5IZfReaYZ0MPadDfa08hQ$>
>
> I commented this code and ran the tests under premain but didn't hit the
> NPE.
>
> I forgot what the problem was, but it happened for very simple cases.
>
> Thanks
>
> - Ioi
>
>
> Thanks,
> - Ashutosh Mehra
>
>
> On Tue, Sep 17, 2024 at 1:11?AM <ioi.lam at oracle.com> wrote:
>
>> Hi Ashutosh,
>>
>> So this looks like a potential bug (or feature) in the core lib code.
>> When CDS forcefully initializes a class in an unexpected (or untested)
>> order, the "initialization soup" fails.
>>
>> Perhaps a work-around would be to make some harmless calls at the place
>> where CDS was calling into MethodType.createArchivedObjects(). E.g., do
>> something like this:
>>
>> +    if (CDSConfig::is_dumping_invokedynamic()) {
>> +       // call into Java: jdk.internal.misc::warmupInvokeDynamic();
>> +   }
>>     // Rewrite and link classes
>>     log_info(cds)("Rewriting and linking classes ...");
>>
>> Maybe you can add a new Lambda expressions, MethodHandle invocations,
>> etc, that would hopefully cause PrimitiveClassDescImpl and friends to be
>> initialized in their natural order.
>>
>> Or call class.forName("java.lang.constant.ConstantDescs") ??
>>
>> BTW, you can see my comments in
>> AOTClassInitializer::is_forced_preinit_class():
>>
>>     // TODO:
>>     // This is needed since JDK-8338532. Without this, when
>>     // archived heap objects are used, the class init order is not
>>     // expected by the jdk/internal/constant bootstrap code and we
>>     // will get a null pointer exception.
>>     //
>>     // When bootstraping has intricated/fragile order, it's probably
>>     // better to archive all related classes in an initialized state
>>     // (i.e., take a snapshot). The existing approach in
>>     // heapShared::resolve_or_init_classes_for_subgraph_of() won't work.
>>     "jdk/internal/constant/PrimitiveClassDescImpl",
>>     "jdk/internal/constant/ReferenceClassDescImpl",
>>     "java/lang/constant/ConstantDescs",
>>     "sun/invoke/util/Wrapper",
>>
>> I was having a similar circularity issue (but in production time) and I
>> just added enough classes to make the NPE go away. For your test case, if
>> you manage to fix in in the assembly run but run into NPE in production
>> run, you might need to add more classes to this list. Yes, it's a hack :-(
>>
>>
>> Thanks
>>
>> - Ioi
>> On 9/13/24 7:05 PM, Ashutosh Mehra wrote:
>>
>> This is turning out to be a real example of class initialization soup!
>> As mentioned during the meeting, I am getting NPE in the assembly phase
>> when testing the patch [0] that I proposed in my earlier mail
>> using a test case inspired by the Infinispan code.
>> NPE occurs when running the class initializer for PrimitiveClassDescImpl
>> Interestingly, PrimitiveClassDescImpl is "forcefully" initialized by
>> MetaspaceShared::link_shared_classes().
>>
>> I couldn't get a stack trace so I relied on exception logs (using
>> -Xlog:exceptions=trace) to find the cause which indicate following frames
>> on the stack:
>>
>> [0]
>> jdk/internal/constant/MethodTypeDescImpl::validateArgument(Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/ClassDesc; @
>> bci 1
>> [1]
>> jdk/internal/constant/MethodTypeDescImpl::ofTrusted(Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljdk/internal/constant/MethodTypeDescImpl; @
>> bci 27
>> [2]
>> java/lang/constant/ConstantDescs::ofConstantBootstrap(Ljava/lang/constant/ClassDesc;Ljava/lang/String;Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/DirectMethodHandleDesc; @
>> bci 47
>> [3] java/lang/constant/ConstantDescs::<clinit> @ bci 664
>> [4]
>> jdk/internal/constant/PrimitiveClassDescImpl::<init>(Ljava/lang/String;)V @
>> bci 1
>> [5]
>> jdk/internal/constant/PrimitiveClassDescImpl::<clinit>(Ljava/lang/String;)V @
>> bci 6
>>
>> Notice that invocation of PrimitiveClassDescImpl::<clinit> results in
>> initialization of ConstantDescs class (see frame 3).
>> ConstantDescs::<clinit> @ 664 corresponds to following java code:
>>
>>     public static final DirectMethodHandleDesc BSM_CLASS_DATA_AT
>>             = ofConstantBootstrap(CD_MethodHandles, "classDataAt",
>>             CD_Object, CD_int);
>>
>> The last parameter CD_int is initialized as:
>>
>>     public static final ClassDesc CD_int = PrimitiveClassDescImpl.CD_int;
>>
>> So, its value is obtained from PrimitiveClassDescImpl.CD_int which
>> hasn't been initialized properly yet. As a result ConstantDescs::CD_int is
>> assigned null which results in MethodTypeDescImpl::validateArgument
>> throwing NPE later.
>> There is a clear class initialization circularity involving
>> PrimitiveClassDescImpl and ConstantDescs, and the result depends on
>> which class gets initialized first.
>>
>> Without my patch this issue is not seen because PrimitiveClassDescImpl
>> has already been initialized by the time
>> MetaspaceShared::link_shared_classes() is called.
>> Its initialization is triggered by the call to
>> MethodType::createArchivedObjects().
>> It also explains why my patch introduced this issue because it
>> effectively moved the call to MethodType::createArchivedObjects() after
>> MetaspaceShared::link_shared_classes().
>>
>> [0]
>> https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>
>> Thanks,
>> - Ashutosh Mehra
>>
>>
>> On Wed, Sep 11, 2024 at 3:12?PM Ashutosh Mehra <asmehra at redhat.com>
>> wrote:
>>
>>> Regarding the WrongMethodTypeException that I mentioned in my previous
>>> email (see pt 3),
>>> this exception happens when lambda proxy class attempts to invoke the
>>> MethodHandle it obtained from the classData:
>>>
>>>   public void accept(java.lang.Object);
>>>     descriptor: (Ljava/lang/Object;)V
>>>     flags: (0x0001) ACC_PUBLIC
>>>     Code:
>>>       stack=3, locals=2, args_size=2
>>>          0: ldc           #26                 // Dynamic
>>> #0:_:Ljava/lang/invoke/MethodHandle;
>>>          2: aload_0
>>>          3: getfield      #13                 // Field
>>> arg$1:Lorg/wildfly/security/WildFlyElytronBaseProvider;
>>>          6: aload_1
>>>          7: checkcast     #28                 // class
>>> java/security/Provider$Service
>>>         10: invokevirtual #34                 // Method
>>> java/lang/invoke/MethodHandle.invokeExact:(Lorg/wildfly/security/WildFlyElytronBaseProvider;Ljava/security/Provider$Service;)V
>>>         13: return
>>>
>>> The scenario is during the assembly phase as part of the indy resolution
>>> the MethodHandle for which the exception is thrown gets created.
>>> Normally MethodHandle's type gets added in MethodType::internTable but
>>> by the time indy resolution happens, JVM has already taken
>>> snapshot of the MethodType::internTable through an upcall to
>>> MethodType::createArchivedObjects().
>>> As a result the AOTCache ends up with the MethodType object which is not
>>> in AOTHolder.archivedMethodTypes.
>>>
>>> During the production run, when the jvm invokes the MethodHandle, it
>>> searches for the MethodType corresponding to the signature passed at the
>>> callsite.
>>> As expected, it fails to find it in the AOTHolder.archivedMethodTypes,
>>> so it creates a new instance of the MethodType.
>>> But Invokers.checkExactType() relies on the MethodHandle's type to be
>>> the same object as the MethodType object passed as parameter.
>>>
>>>     static void checkExactType(MethodHandle mhM, MethodType expected) {
>>>         MethodType targetType = mh.type();
>>>         if (targetType != expected)
>>>             throw newWrongMethodTypeException(targetType, expected);
>>>     }
>>>
>>> Hence, it throws WrongMethodTypeException though the two MT objects
>>> have the same signature.
>>>
>>> To handle this scenario, I changed the order of indy resolution and upcall
>>> to MethodType::createArchivedObjects() as:
>>>
>>> diff --git a/src/hotspot/share/cds/metaspaceShared.cpp
>>> b/src/hotspot/share/cds/metaspaceShared.cpp
>>> index df4bcadefa3..457716cac5b 100644
>>> --- a/src/hotspot/share/cds/metaspaceShared.cpp
>>> +++ b/src/hotspot/share/cds/metaspaceShared.cpp
>>> @@ -751,6 +751,20 @@ void MetaspaceShared::link_shared_classes(bool
>>> jcmd_request, TRAPS) {
>>>    if (CDSConfig::is_dumping_final_static_archive()) {
>>>      FinalImageRecipes::apply_recipes(CHECK);
>>>    }
>>> +
>>> +#if INCLUDE_CDS_JAVA_HEAP
>>> +  if (CDSConfig::is_dumping_invokedynamic()) {
>>> +    // This makes sure that the MethodType and MethodTypeForm tables
>>> won't be updated
>>> +    // concurrently when we are saving their contents into a side table.
>>> +    assert(CDSConfig::allow_only_single_java_thread(), "Required");
>>> +
>>> +    JavaValue result(T_VOID);
>>> +    JavaCalls::call_static(&result, vmClasses::MethodType_klass(),
>>> +                           vmSymbols::createArchivedObjects(),
>>> +                           vmSymbols::void_method_signature(),
>>> +                           CHECK);
>>> +  }
>>> +#endif
>>>  }
>>>
>>> Note that indy resolution happens as part of FinalImageRecipes::apply_recipes(CHECK)
>>> which is now invoked before the upcall to createArchivedObjects().
>>> With this change I am able to run the application without any exceptions.
>>> My complete patch can be seen here:
>>> https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>> I will do more testing with this patch.
>>>
>>> @Ioi Lam <ioi.lam at oracle.com> do you have any feedback on this patch.
>>>
>>> Thanks,
>>> - Ashutosh Mehra
>>>
>>>
>>>
>>> On Wed, Sep 11, 2024 at 10:14?AM Ashutosh Mehra <asmehra at redhat.com>
>>> wrote:
>>>
>>>> Hi Andrew,
>>>> Thanks for sharing the initial investigation.
>>>> I have been looking into this and have a few of things to add to your
>>>> analysis:
>>>>
>>>> 1.  As you mentioned the classData for the lambda
>>>> class WildFlyElytronBaseProvider$$Lambda is null.
>>>> The classData is stored in the mirror object of the InstanceKlass when
>>>> the class is defined through JVM_LookupDefineClass.
>>>> However, when we create the scratch mirror object (which get stored in
>>>> the AOT cache) the classData is not populated.
>>>> See
>>>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp#L1128-L1131
>>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp*L1128-L1131__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhbKjzG3gw$>
>>>>
>>>>   Handle classData; // set to null. Will be reinitialized at runtime
>>>>   Handle mirror;
>>>>   Handle comp_mirror;
>>>>   allocate_mirror(k, /*is_scratch=*/true, protection_domain, classData,
>>>> mirror, comp_mirror, CHECK);
>>>>
>>>> So this explains why the call to classData(caller.lookupClass())
>>>> returned null.
>>>>
>>>> 2. In the mainline there is a check in InnerClassLambdaMetafactory.java
>>>> for the particular code pattern used by the application.
>>>> If this code pattern is found then the lambda proxy class is not
>>>> included in the CDS archive.
>>>> See
>>>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L163-L170
>>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L163-L170__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZl2S9tQg$>
>>>> and
>>>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L246
>>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L246__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhYsI3Xx0g$>
>>>>
>>>>         // If the target class invokes a protected method inherited
>>>> from a
>>>>         // superclass in a different package, or does 'invokespecial',
>>>> the
>>>>         // lambda class has no access to the resolved method, or does
>>>>         // 'invokestatic' on a hidden class which cannot be resolved by
>>>> name.
>>>>         // Instead, we need to pass the live implementation method
>>>> handle to
>>>>         // the proxy class to invoke directly. (javac prefers to avoid
>>>> this
>>>>         // situation by generating bridges in the target class)
>>>>         useImplMethodHandle =
>>>> (Modifier.isProtected(implInfo.getModifiers()) &&
>>>>                                !VerifyAccess.isSamePackage(targetClass,
>>>> implInfo.getDeclaringClass())) ||
>>>>                                implKind ==
>>>> MethodHandleInfo.REF_invokeSpecial ||
>>>>                                implKind ==
>>>> MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>>>>
>>>> In premain lambda proxy classes get included in the AOT cache as a
>>>> result of indy resolution and that mechanism doesn't have this kind of
>>>> check.
>>>>
>>>> 3. For the null classData problem mentioned above, I tried to fix it by
>>>> storing classData in the scratch mirror using the following patch:
>>>>
>>>> diff --git a/src/hotspot/share/classfile/javaClasses.cpp
>>>> b/src/hotspot/share/classfile/javaClasses.cpp
>>>> index bd8141adbcc..41766e98093 100644
>>>> --- a/src/hotspot/share/classfile/javaClasses.cpp
>>>> +++ b/src/hotspot/share/classfile/javaClasses.cpp
>>>> @@ -1094,9 +1094,9 @@ void java_lang_Class::create_mirror(Klass* k,
>>>> Handle class_loader,
>>>>      }
>>>>      if (CDSConfig::is_dumping_heap()) {
>>>>        if (CDSConfig::is_dumping_protection_domains()) {
>>>> -        create_scratch_mirror(k, protection_domain, CHECK);
>>>> +        create_scratch_mirror(k, protection_domain, classData, CHECK);
>>>>        } else {
>>>> -        create_scratch_mirror(k, Handle() /* null protection_domain*/,
>>>> CHECK);
>>>> +        create_scratch_mirror(k, Handle() /* null protection_domain*/,
>>>> classData, CHECK);
>>>>        }
>>>>      }
>>>>    } else {
>>>> @@ -1117,7 +1117,7 @@ void java_lang_Class::create_mirror(Klass* k,
>>>> Handle class_loader,
>>>>  // Note: we archive the "scratch mirror" instead of k->java_mirror(),
>>>> because the
>>>>  // latter may contain dumptime-specific information that cannot be
>>>> archived
>>>>  // (e.g., ClassLoaderData*, or static fields that are modified by Java
>>>> code execution).
>>>> -void java_lang_Class::create_scratch_mirror(Klass* k, Handle
>>>> protection_domain, TRAPS) {
>>>> +void java_lang_Class::create_scratch_mirror(Klass* k, Handle
>>>> protection_domain, Handle classData, TRAPS) {
>>>>    if (k->class_loader() != nullptr &&
>>>>        k->class_loader() != SystemDictionary::java_platform_loader() &&
>>>>        k->class_loader() != SystemDictionary::java_system_loader()) {
>>>> @@ -1125,9 +1125,11 @@ void
>>>> java_lang_Class::create_scratch_mirror(Klass* k, Handle protection_domain,
>>>>      return;
>>>>    }
>>>>
>>>> -  Handle classData; // set to null. Will be reinitialized at runtime
>>>> +  //Handle classData; // set to null. Will be reinitialized at runtime
>>>>    Handle mirror;
>>>>    Handle comp_mirror;
>>>>    allocate_mirror(k, /*is_scratch=*/true, protection_domain,
>>>> classData, mirror, comp_mirror, CHECK);
>>>>
>>>>    if (comp_mirror() != nullptr) {
>>>> diff --git a/src/hotspot/share/classfile/javaClasses.hpp
>>>> b/src/hotspot/share/classfile/javaClasses.hpp
>>>> index bc49a0861a7..7ec2a2556dd 100644
>>>> --- a/src/hotspot/share/classfile/javaClasses.hpp
>>>> +++ b/src/hotspot/share/classfile/javaClasses.hpp
>>>> @@ -263,7 +263,7 @@ class java_lang_Class : AllStatic {
>>>>
>>>>    // Archiving
>>>>    static void serialize_offsets(SerializeClosure* f) NOT_CDS_RETURN;
>>>> -  static void create_scratch_mirror(Klass* k, Handle
>>>> protection_domain, TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>>>> +  static void create_scratch_mirror(Klass* k, Handle
>>>> protection_domain, Handle classData, TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>>>>    static bool restore_archived_mirror(Klass *k, Handle class_loader,
>>>> Handle module,
>>>>                                        Handle protection_domain,
>>>>                                        TRAPS)
>>>> NOT_CDS_JAVA_HEAP_RETURN_(false);
>>>>
>>>> But this resulted in a different exception:
>>>>
>>>> Exception in thread "main" java.lang.ExceptionInInitializerError
>>>> at com.redhat.leyden.Main.main(Main.java:7)
>>>> Caused by: java.lang.invoke.WrongMethodTypeException: handle's method
>>>> type (WildFlyElytronBaseProvider,Service)void but found
>>>> (WildFlyElytronBaseProvider,Service)void
>>>> at
>>>> java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>>>> at java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>>>> at
>>>> java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
>>>> at
>>>> org.wildfly.security.WildFlyElytronBaseProvider$$Lambda/0x80000000c.accept(Unknown
>>>> Source)
>>>> at
>>>> org.wildfly.security.WildFlyElytronBaseProvider.putMakedPasswordImplementations(WildFlyElytronBaseProvider.java:112)
>>>> at
>>>> org.wildfly.security.WildFlyElytronBaseProvider.putPasswordImplementations(WildFlyElytronBaseProvider.java:107)
>>>> at
>>>> org.wildfly.security.password.WildFlyElytronPasswordProvider.<init>(WildFlyElytronPasswordProvider.java:43)
>>>> at
>>>> org.wildfly.security.password.WildFlyElytronPasswordProvider.<clinit>(WildFlyElytronPasswordProvider.java:36)
>>>> ... 1 more
>>>>
>>>> The exception message is strange because the handle's method type and
>>>> the expected type are both symbolically the same.
>>>> I am debugging this exception at the moment.
>>>>
>>>> Thanks,
>>>> - Ashutosh Mehra
>>>>
>>>>
>>>> On Wed, Sep 11, 2024 at 6:03?AM Andrew Dinn <adinn at redhat.com> wrote:
>>>>
>>>>> Oops, sorry, I debugged this a few days ago! Correction to a few
>>>>> details:
>>>>>
>>>>> On 11/09/2024 10:39, Andrew Dinn wrote:
>>>>> > A crash due to an NPE was observed in the Infinispan (Data Grid)
>>>>> server
>>>>> > app when deployed using the Leyden EA. The crash still manifests
>>>>> with
>>>>> > the latest premain code. The crash happens below an application call
>>>>> > which employs a method reference as argument
>>>>> >
>>>>> >          putMakedPasswordImplementations(this::putService, this);
>>>>>
>>>>> The called method in turn calls consumer.accept
>>>>>
>>>>>              consumer.accept(new Service(provider,
>>>>> PASSWORD_FACTORY_TYPE, algorithm,
>>>>> "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>>>> emptyList,
>>>>> emptyMap));
>>>>>
>>>>> which enters enters MethodHandleNative::linkDynamicConstant()
>>>>>
>>>>> > Debugging shows that the call to linkDynamicConstant() returns null.
>>>>> >
>>>>> > A simple reproducer for the problem is available as a maven project
>>>>> on
>>>>> > github:
>>>>> >
>>>>> >    https://github.com/tristantarrant/elytron-leyden
>>>>> <https://urldefense.com/v3/__https://github.com/tristantarrant/elytron-leyden__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZaZr1akQ$>
>>>>> >
>>>>> > The ReadMe provides an explanation of how to reproduce the problem.
>>>>> I
>>>>> > did so and the debugged to find out some of the details of what is
>>>>> > happening (see below) but did not fully clarify the problem. Help
>>>>> from
>>>>> > someone more conversant with the ins and outs of method handle
>>>>> > bootstraps in premain would be welcome. Details follow.
>>>>> >
>>>>> > regards,
>>>>> >
>>>>> >
>>>>> > Andrew Dinn
>>>>> > -----------
>>>>> >
>>>>> > I downloaded the git repo and attached the Java sources using Maven
>>>>> command
>>>>> >
>>>>> >    $ mvn dependency:sources
>>>>> >
>>>>> > Having manifested the crash by following the instructions in the
>>>>> README
>>>>> > I reran the leyden JVM under gdb using the following commands to
>>>>> enable
>>>>> > Java debugging
>>>>> >
>>>>> > $ gdb ${LEYDEN_HOME}/bin/java
>>>>> > (gdb) cd /path/to/mvn/project
>>>>> > (gdb) run
>>>>> > -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
>>>>> > -classpath
>>>>> >
>>>>> /home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/
>>>>> 2.5.1.
>>>>> <https://urldefense.com/v3/__http://2.5.1.__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhauJ-RjcQ$>Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar
>>>>> -XX:CacheDataStore=elytron.aot com.redhat.leyden.Main
>>>>> >
>>>>> > The problem manifests at WildflyElytronBaseProvider.java:112 in
>>>>> method
>>>>> > WildflyElytronBaseProvider::putMakedPasswordImplementations
>>>>>
>>>>>      static void putMakedPasswordImplementations(Consumer<Service>
>>>>> consumer, Provider provider) {
>>>>>          for (String algorithm : MASKED_ALGORITHMS) {
>>>>>              consumer.accept(new Service(provider,
>>>>> PASSWORD_FACTORY_TYPE, algorithm,
>>>>> "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>>>> emptyList,
>>>>> emptyMap)); <== NPE under this call
>>>>>          }
>>>>>
>>>>>
>>>>> > The source code for this method can be found in the following source
>>>>> jar
>>>>> >
>>>>> >
>>>>> >
>>>>> ${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar
>>>>> >
>>>>> > (where M2_REPO will normally be ~/.m2/repository)
>>>>> >
>>>>> > Stepping into accept eventually enters
>>>>> MethodHandleNative::linkDynamicConstant
>>>>> > which in turn enters into ConstantBootstraps.makeConstant(). The
>>>>> caller
>>>>> > Class at this point is a lambda class which prints as
>>>>> > org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c
>>>>> >
>>>>> > Several steps further the code enters BootstrapMethodInvoker::invoke
>>>>> > (below the app method call but via 3 hidden frames) with
>>>>> bootstrapMethod
>>>>> > bound to a DirectMethodHandle. After several more steps this enters
>>>>> > DirectMethodHandle$Holder.invokeStatic which in turn calls
>>>>> > MethodHandles::classData(Lookup,String,Class).
>>>>> >
>>>>> > At this point caller is a MethodHandleLookup for the lambda class
>>>>> > Lambda/0x800000000c mentioned above. The following call
>>>>> >
>>>>> >           Object classdata = classData(caller.lookupClass());
>>>>> >
>>>>> > returns null to DirectMethodHandle$Holder.invokeStatic which pops
>>>>> the
>>>>> > same result back out to BootstrapMethodInvoker::invoke at line 90
>>>>> >
>>>>> >                  if (type instanceof Class<?> c) {
>>>>> >                      result = bootstrapMethod.invoke(caller, name,
>>>>> c);
>>>>> > <== null
>>>>> >
>>>>> > This null result pops back out as the value for the call to
>>>>> > BootstrapMethodInvoker.invoke(), ConstantBootstraps.makeConstant()
>>>>> and
>>>>> > MethodHandleNative::linkDynamicConstant().
>>>>> >
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240919/471fea43/attachment.htm>

From adinn at openjdk.org  Thu Sep 19 15:13:14 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 19 Sep 2024 15:13:14 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v3]
In-Reply-To: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
Message-ID: <7B-U_931UAHJ1N2D8QXCYKEAg0fgdXMJwRbRRBLLe-s=.b4d2b34d-2256-49a4-ab74-c12ec7aa2dfa@github.com>

> This PR modifies AOT compiled method code to load compressed oops base and shift constants via the AOTRuntimeConstants area rather than encode them as immediates. It also unlatches the currently forced setting of UseCompatibleCompressedOops, allowing the heap to be allocated wherever it will fit.

Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:

  Answer further review feedback

-------------

Changes:
  - all: https://git.openjdk.org/leyden/pull/20/files
  - new: https://git.openjdk.org/leyden/pull/20/files/ce901a9d..243d72d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=leyden&pr=20&range=02
 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=20&range=01-02

  Stats: 6 lines in 2 files changed: 2 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/leyden/pull/20.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/20/head:pull/20

PR: https://git.openjdk.org/leyden/pull/20

From adinn at openjdk.org  Thu Sep 19 15:48:44 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 19 Sep 2024 15:48:44 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v2]
In-Reply-To: <khnEAEVHg8y3-Q0dAiJN1WJ1aSFxm8bv0F1gyYDrUq4=.f0d1d6fc-d37f-40db-a4ee-7addb3ea92b9@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
 <shiGolUnmKfaNTi1qlO-P0TD7pASS1QgVyMLU5AZxpg=.189f8b78-ac35-40fb-ac9d-31714e050581@github.com>
 <khnEAEVHg8y3-Q0dAiJN1WJ1aSFxm8bv0F1gyYDrUq4=.f0d1d6fc-d37f-40db-a4ee-7addb3ea92b9@github.com>
Message-ID: <vsROhPD43osePQHmqDdnmcjtIUJ1hgEYocfk7MH4ThA=.76d27d5d-c864-4e5c-8af9-e6e22f790bd0@github.com>

On Thu, 12 Sep 2024 23:13:21 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   only check UseCompatibleCompressedOops on 64 bit builds
>
> Thinking more.
> 
> On other hand, only AOT code will suffer. Recompiled code will be optimal which is good for peak performance.
> And with UseCompatibleCompressedOops recompiled code will also suffer.
> 
> I need to see numbers how it affect performance of AOT code.  I hope CPU's prefetcher will keep these values nearby.

@vnkozlov I pushed fixes for your feedback and then planned to get some performance numbers. However, when I rebuilt (on aarch64) and retested a simple javac HelloWorld I got a ClassCastEception from the production run:

java.lang.ClassCastException: class java.util.HashMap$Node cannot be cast to class java.util.HashMap$TreeNode (java.util.HashMap$Node and java.util.HashMap$TreeNode are in module java.base of loader 'bootstrap')


This is happening in the interpreter when executing HashMap::putVal in this code

            Node<K,V> e; K k;
            if (p.hash == hash &&
                ((k = p.key) == key || (key != null && key.equals(k))))
                e = p;
            else if (p instanceof TreeNode)
                e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
            else {
                for (int binCount = 0; ; ++binCount) {

The callout to the exception handler happens at bytecode 114

     104: aload         7
     106: instanceof    #173                // class java/util/HashMap$TreeNode
     109: ifeq          131
     112: aload         7
     114: checkcast     #173                // class java/util/HashMap$TreeNode
     117: aload_0
     118: aload         6

I looked at the oop in local 7 and it is indeed an instance of HashMap$Node, not HashMap$Treenode. We load both C1 and C2 code from the AOT code cache for this method. So, I supsect this may be a deopt issue. I'll try to catch the deopt callout and see if I can work out where it might be going wrong.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/20#issuecomment-2361386128

From ioi.lam at oracle.com  Thu Sep 19 19:51:28 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Thu, 19 Sep 2024 12:51:28 -0700
Subject: premain: Crash in Infinispan server code caused by NPE under
 MethodHandleNative::linkDynamicConstant
In-Reply-To: <CAKt0pyRj8_mDiH58v10sqXNHA4iHja6-7D9N_S2VW9rhESPcTw@mail.gmail.com>
References: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
 <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>
 <CAKt0pySztvwsadtrqjai6XwakAWq_v_o8men4aopLo4X-0azyQ@mail.gmail.com>
 <CAKt0pyQ44E+npyUW35Zhxg+PfBgF2yuNgS61gj1GGj=aLGTJXw@mail.gmail.com>
 <CAKt0pyT48uPH6rUL7bEJ2rtWqNdNL34DWBJ2SDaHwYfVxURnQw@mail.gmail.com>
 <0d22d580-39a1-4105-a50e-8a74a555090d@oracle.com>
 <CAKt0pyRYBNtkLzVoAfDHWE=4e+9efZFb+xKYZv-d3LpDAU4qZg@mail.gmail.com>
 <da797fe2-137c-4fc7-a67c-3b595c0c63f2@oracle.com>
 <CAKt0pyRj8_mDiH58v10sqXNHA4iHja6-7D9N_S2VW9rhESPcTw@mail.gmail.com>
Message-ID: <45e62b78-bbde-4ba5-8b20-77125d14b908@oracle.com>


On 9/19/24 7:44 AM, Ashutosh Mehra wrote:
>
>     As I am cleaning up the code for upstreaming to mainline, I am
>     going add an equivalent check in the C code to filter out these
>     indy call sites, so they won't be resolved at all during the
>     assembly phase. Otherwise, I will run into problems described in
>     https://bugs.openjdk.org/browse/JDK-8290417
>
>
> Thanks for the link to the bug. The scenario described in that bug is 
> exactly the same as the Infinispan case.
> So if we filter out such cases during indy resolution then it should 
> resolve the Infinispan issue as well.
>
> A basic question: why?can't CDS handle the lambda proxy class 
> generated in useImplMethodHandle?mode?
>
If I remember correctly, it has to do with the shape of dynamically 
generated bytecode:

 ? public void accept(java.lang.Object);
 ??? Code:
 ?????? 0: ldc #28 // Dynamic #0:_:Ljava/lang/invoke/MethodHandle;
 ?????? 2: aload_0
 ?????? 3: getfield #15 // Field arg$1:LTester;
 ?????? 6: aload_1
 ?????? 7: checkcast #30 // class java/lang/String
 ????? 10: invokevirtual #36 // Method 
java/lang/invoke/MethodHandle.invokeExact:(LTester;Ljava/lang/String;)V
 ????? 13: return

The result of the "ldc" was not symbolically encoded in the generated 
class (as the generated class has no permission to access that method). 
So the MethodHandle is stored as a binary object in the mirror of this 
generated class (with the java.lang.Class::classData field).

Plain CDS doesn't archive class mirrors, so the classData will be lost.

With JEP 483, we should be able to preserve the classData, so I am not 
sure why the useImplMethodHandle case is still failing. My plan is to 
filter these out for now, but I will get back to it later when I have 
more time.

Thanks

- Ioi




> Thanks,
> - Ashutosh Mehra
>
>
> On Thu, Sep 19, 2024 at 1:45?AM <ioi.lam at oracle.com> wrote:
>
>     Hi Ashutosh,
>
>     I have some update:
>
>     The original crash was caused by the "useImplMethodHandle" code in
>     InnerClassLambdaMetafactory.java:
>
>     ??????? // If the target class invokes a protected method
>     inherited from a
>     ??????? // superclass in a different package, or does
>     'invokespecial', the
>     ??????? // lambda class has no access to the resolved method, or does
>     ??????? // 'invokestatic' on a hidden class which cannot be
>     resolved by name.
>     ??????? // Instead, we need to pass the live implementation method
>     handle to
>     ??????? // the proxy class to invoke directly. (javac prefers to
>     avoid this
>     ??????? // situation by generating bridges in the target class)
>     ??????? useImplMethodHandle =
>     (Modifier.isProtected(implInfo.getModifiers()) &&
>     !VerifyAccess.isSamePackage(targetClass,
>     implInfo.getDeclaringClass())) ||
>     ?????????????????????????????? implKind ==
>     MethodHandleInfo.REF_invokeSpecial ||
>     ?????????????????????????????? implKind ==
>     MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>
>     As I am cleaning up the code for upstreaming to mainline, I am
>     going add an equivalent check in the C code to filter out these
>     indy call sites, so they won't be resolved at all during the
>     assembly phase. Otherwise, I will run into problems described in
>     https://bugs.openjdk.org/browse/JDK-8290417
>
>     Once I get the filtering code working, I will integrate it back to
>     premain.
>
>     >I am wondering if we can workaround class circularity issues by
>     recording class initialization order
>     >during training run and use that to guide the initialization
>     during assembly phase.
>
>     In the production run we take different paths than the training run
>
>     (1) some classes are aot-initialized (especially the enums)
>     (2) some classes make special CDS calls
>
>     so I am not sure if it's possible to get the same initialization
>     order as in the training run (or assembly phase).
>
>     (more below)
>
>     On 9/18/24 9:10 AM, Ashutosh Mehra wrote:
>>     Hi Ioi,
>>
>>         I was having a similar circularity issue (but in production
>>         time) and I just added enough classes to make the NPE go away.
>>
>>     I am wondering if you have a test case that reproduces the NPE
>>     which prompted you to add these classes:
>>
>>     https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp#L65-L78
>>     <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp*L65-L78__;Iw!!ACWV5N9M2RV99hQ!NYvqLbb_Ib2kSdm2fcYVLGby-AiB2TG7KtC1HQHVKLiM-_kRb5mOt8krV5IZfReaYZ0MPadDfa08hQ$>
>>
>>     I commented this code and ran the tests under premain but didn't
>>     hit?the NPE.
>>
>     I forgot what the problem was, but it happened for very simple cases.
>
>     Thanks
>
>     - Ioi
>
>
>>     Thanks,
>>     - Ashutosh Mehra
>>
>>
>>     On Tue, Sep 17, 2024 at 1:11?AM <ioi.lam at oracle.com> wrote:
>>
>>         Hi Ashutosh,
>>
>>         So this looks like a potential bug (or feature) in the core
>>         lib code. When CDS forcefully initializes a class in an
>>         unexpected (or untested) order, the "initialization soup" fails.
>>
>>         Perhaps a work-around would be to make some harmless calls at
>>         the place where CDS was calling into
>>         MethodType.createArchivedObjects(). E.g., do something like this:
>>
>>         +??? if (CDSConfig::is_dumping_invokedynamic()) {
>>         +?????? // call into Java:
>>         jdk.internal.misc::warmupInvokeDynamic();
>>         +?? }
>>         ??? // Rewrite and link classes
>>         ??? log_info(cds)("Rewriting and linking classes ...");
>>
>>         Maybe you can add a new Lambda expressions, MethodHandle
>>         invocations, etc, that would hopefully cause
>>         PrimitiveClassDescImpl and friends to be initialized in their
>>         natural order.
>>
>>         Or call class.forName("java.lang.constant.ConstantDescs") ??
>>
>>         BTW, you can see my comments in
>>         AOTClassInitializer::is_forced_preinit_class():
>>
>>         ??? // TODO:
>>         ??? // This is needed since JDK-8338532. Without this, when
>>         ??? // archived heap objects are used, the class init order
>>         is not
>>         ??? // expected by the jdk/internal/constant bootstrap code
>>         and we
>>         ??? // will get a null pointer exception.
>>         ??? //
>>         ??? // When bootstraping has intricated/fragile order, it's
>>         probably
>>         ??? // better to archive all related classes in an
>>         initialized state
>>         ??? // (i.e., take a snapshot). The existing approach in
>>         ??? // heapShared::resolve_or_init_classes_for_subgraph_of()
>>         won't work.
>>         "jdk/internal/constant/PrimitiveClassDescImpl",
>>         "jdk/internal/constant/ReferenceClassDescImpl",
>>         ??? "java/lang/constant/ConstantDescs",
>>         ??? "sun/invoke/util/Wrapper",
>>
>>         I was having a similar circularity issue (but in production
>>         time) and I just added enough classes to make the NPE go
>>         away. For your test case, if you manage to fix in in the
>>         assembly run but run into NPE in production run, you might
>>         need to add more classes to this list. Yes, it's a hack :-(
>>
>>
>>         Thanks
>>
>>         - Ioi
>>
>>         On 9/13/24 7:05 PM, Ashutosh Mehra wrote:
>>>         This is turning out to be a real example of class
>>>         initialization soup!
>>>         As mentioned during the meeting, I am getting NPE in the
>>>         assembly phase when testing the patch [0] that I proposed in
>>>         my earlier mail
>>>         using a test case inspired by the Infinispan code.
>>>         NPE occurs when running the class initializer for
>>>         PrimitiveClassDescImpl
>>>         Interestingly, PrimitiveClassDescImpl?is "forcefully"
>>>         initialized by MetaspaceShared::link_shared_classes().
>>>
>>>         I couldn't get a stack trace so I relied on exception logs
>>>         (using -Xlog:exceptions=trace) to find the cause which
>>>         indicate following frames on the stack:
>>>
>>>         [0]
>>>         jdk/internal/constant/MethodTypeDescImpl::validateArgument(Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/ClassDesc;?@
>>>         bci 1
>>>         [1]
>>>         jdk/internal/constant/MethodTypeDescImpl::ofTrusted(Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljdk/internal/constant/MethodTypeDescImpl;?@
>>>         bci 27
>>>         [2]
>>>         java/lang/constant/ConstantDescs::ofConstantBootstrap(Ljava/lang/constant/ClassDesc;Ljava/lang/String;Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/DirectMethodHandleDesc;?@
>>>         bci 47
>>>         [3] java/lang/constant/ConstantDescs::<clinit>?@ bci 664
>>>         [4]
>>>         jdk/internal/constant/PrimitiveClassDescImpl::<init>(Ljava/lang/String;)V?@
>>>         bci 1
>>>         [5]
>>>         jdk/internal/constant/PrimitiveClassDescImpl::<clinit>(Ljava/lang/String;)V?@
>>>         bci 6
>>>
>>>         Notice?that invocation of PrimitiveClassDescImpl::<clinit>
>>>         results in initialization of ConstantDescs?class (see frame 3).
>>>         ConstantDescs::<clinit>?@ 664 corresponds to following java
>>>         code:
>>>
>>>         ? ? public static final DirectMethodHandleDesc BSM_CLASS_DATA_AT
>>>         = ofConstantBootstrap(CD_MethodHandles, "classDataAt",
>>>         ? ? ? ? ? ? CD_Object, CD_int);
>>>
>>>         The last parameter CD_int is initialized as:
>>>
>>>         ? ? public static final ClassDesc CD_int =
>>>         PrimitiveClassDescImpl.CD_int;
>>>
>>>         So, its value is obtained from
>>>         PrimitiveClassDescImpl.CD_int?which hasn't been initialized
>>>         properly yet. As a result ConstantDescs::CD_int is
>>>         assigned?null which results in
>>>         MethodTypeDescImpl::validateArgument throwing NPE later.
>>>         There is a clear class initialization circularity involving
>>>         PrimitiveClassDescImpl and ConstantDescs, and the result
>>>         depends on which class gets initialized first.
>>>
>>>         Without my patch this issue is not seen because
>>>         PrimitiveClassDescImpl has already been initialized by the
>>>         time MetaspaceShared::link_shared_classes()?is called.
>>>         Its initialization is triggered by the call to
>>>         MethodType::createArchivedObjects().
>>>         It also explains why my patch introduced this issue because
>>>         it effectively moved the call to
>>>         MethodType::createArchivedObjects() after
>>>         MetaspaceShared::link_shared_classes().
>>>
>>>         [0]
>>>         https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>>         <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>>
>>>         Thanks,
>>>         - Ashutosh Mehra
>>>
>>>
>>>         On Wed, Sep 11, 2024 at 3:12?PM Ashutosh Mehra
>>>         <asmehra at redhat.com> wrote:
>>>
>>>             Regarding the WrongMethodTypeException that I mentioned
>>>             in my previous email (see pt 3),
>>>             this exception happens when lambda proxy class attempts
>>>             to invoke the MethodHandle it obtained from the classData:
>>>
>>>             ? public void accept(java.lang.Object);
>>>             ? ? descriptor: (Ljava/lang/Object;)V
>>>             ? ? flags: (0x0001) ACC_PUBLIC
>>>             ? ? Code:
>>>             ? ? ? stack=3, locals=2, args_size=2
>>>             ? ? ? ? ?0: ldc ? ? ? ? ? #26 ? ? ? // Dynamic
>>>             #0:_:Ljava/lang/invoke/MethodHandle;
>>>             ? ? ? ? ?2: aload_0
>>>             ? ? ? ? ?3: getfield ? ? ?#13 ? ? ? // Field
>>>             arg$1:Lorg/wildfly/security/WildFlyElytronBaseProvider;
>>>             ? ? ? ? ?6: aload_1
>>>             ? ? ? ? ?7: checkcast ? ? #28 ? ? ? // class
>>>             java/security/Provider$Service
>>>             ? ? ? ? 10: invokevirtual #34 ? ? ? // Method
>>>             java/lang/invoke/MethodHandle.invokeExact:(Lorg/wildfly/security/WildFlyElytronBaseProvider;Ljava/security/Provider$Service;)V
>>>             ? ? ? ? 13: return
>>>
>>>             The scenario is during the assembly phase as part of the
>>>             indy resolution the MethodHandle for which the exception
>>>             is thrown gets created.
>>>             Normally MethodHandle's type gets added in
>>>             MethodType::internTable but by the time indy resolution
>>>             happens, JVM has already taken
>>>             snapshot of the MethodType::internTable through an
>>>             upcall to MethodType::createArchivedObjects().
>>>             As a result the AOTCache ends up with the MethodType
>>>             object which is not in AOTHolder.archivedMethodTypes.
>>>
>>>             During the production run, when the jvm invokes the
>>>             MethodHandle, it searches for the MethodType
>>>             corresponding to the signature passed at the callsite.
>>>             As expected, it fails to find it in the
>>>             AOTHolder.archivedMethodTypes, so it creates a new
>>>             instance of the MethodType.
>>>             But Invokers.checkExactType() relies on the
>>>             MethodHandle's?type to be the same object as the
>>>             MethodType object passed as parameter.
>>>
>>>             ? ? static void checkExactType(MethodHandle mhM,
>>>             MethodType expected) {
>>>             MethodType targetType = mh.type();
>>>             ? ? ? ? if (targetType != expected)
>>>             ? ? ? ? ? ? throw
>>>             newWrongMethodTypeException(targetType, expected);
>>>             ? ? }
>>>
>>>             Hence, it throws WrongMethodTypeException?though the two
>>>             MT objects have the same signature.
>>>
>>>             To handle this scenario, I changed the order of indy
>>>             resolution and upcall to
>>>             MethodType::createArchivedObjects()?as:
>>>
>>>             diff --git a/src/hotspot/share/cds/metaspaceShared.cpp
>>>             b/src/hotspot/share/cds/metaspaceShared.cpp
>>>             index df4bcadefa3..457716cac5b 100644
>>>             --- a/src/hotspot/share/cds/metaspaceShared.cpp
>>>             +++ b/src/hotspot/share/cds/metaspaceShared.cpp
>>>             @@ -751,6 +751,20 @@ void
>>>             MetaspaceShared::link_shared_classes(bool jcmd_request,
>>>             TRAPS) {
>>>             ? ?if (CDSConfig::is_dumping_final_static_archive()) {
>>>             ?FinalImageRecipes::apply_recipes(CHECK);
>>>             ? ?}
>>>             +
>>>             +#if INCLUDE_CDS_JAVA_HEAP
>>>             + ?if (CDSConfig::is_dumping_invokedynamic()) {
>>>             + ? ?// This makes sure that the MethodType and
>>>             MethodTypeForm tables won't be updated
>>>             + ? ?// concurrently when we are saving their contents
>>>             into a side table.
>>>             + ?assert(CDSConfig::allow_only_single_java_thread(),
>>>             "Required");
>>>             +
>>>             + ? ?JavaValue result(T_VOID);
>>>             + ?JavaCalls::call_static(&result,
>>>             vmClasses::MethodType_klass(),
>>>             + vmSymbols::createArchivedObjects(),
>>>             + vmSymbols::void_method_signature(),
>>>             + ? ? ? ? ? ? ? ? ? ? ? ? ? CHECK);
>>>             + ?}
>>>             +#endif
>>>             ?}
>>>             Note that indy resolution happens as part of
>>>             FinalImageRecipes::apply_recipes(CHECK) which is now
>>>             invoked before the upcall to createArchivedObjects().
>>>             With this change I am able to run the application
>>>             without any exceptions.
>>>             My complete patch can be seen here:
>>>             https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>>             <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>>             I will do more testing with this patch.
>>>
>>>             @Ioi Lam <mailto:ioi.lam at oracle.com>?do you have any
>>>             feedback on this patch.
>>>
>>>             Thanks,
>>>             - Ashutosh Mehra
>>>
>>>
>>>
>>>             On Wed, Sep 11, 2024 at 10:14?AM Ashutosh Mehra
>>>             <asmehra at redhat.com> wrote:
>>>
>>>                 Hi Andrew,
>>>                 Thanks for sharing the initial investigation.
>>>                 I have been looking into this and have a few of
>>>                 things to add to your analysis:
>>>
>>>                 1.? As you mentioned the classData for the lambda
>>>                 class?WildFlyElytronBaseProvider$$Lambda is null.
>>>                 The classData is stored in the mirror object of the
>>>                 InstanceKlass when the class is defined
>>>                 through?JVM_LookupDefineClass.
>>>                 However, when we create the scratch mirror object
>>>                 (which get stored in the AOT cache) the classData is
>>>                 not populated.
>>>                 See
>>>                 https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp#L1128-L1131
>>>                 <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp*L1128-L1131__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhbKjzG3gw$>
>>>
>>>                 ? Handle classData; // set to null. Will be
>>>                 reinitialized at runtime
>>>                 ? Handle mirror;
>>>                 ? Handle comp_mirror;
>>>                 ? allocate_mirror(k, /*is_scratch=*/true,
>>>                 protection_domain, classData, mirror, comp_mirror,
>>>                 CHECK);
>>>
>>>                 So this explains why the call to
>>>                 classData(caller.lookupClass())returned null.
>>>
>>>                 2. In the mainline there is a check
>>>                 in?InnerClassLambdaMetafactory.java for the
>>>                 particular code pattern used by the application.
>>>                 If this code pattern is found then the lambda proxy
>>>                 class is not included in the CDS archive.
>>>                 See
>>>                 https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L163-L170
>>>                 <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L163-L170__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZl2S9tQg$>
>>>                 and
>>>                 https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L246
>>>                 <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L246__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhYsI3Xx0g$>
>>>
>>>                 ? ? ? ? // If the target class invokes a protected
>>>                 method inherited from a
>>>                 ? ? ? ? // superclass in a different package, or
>>>                 does 'invokespecial', the
>>>                 ? ? ? ? // lambda class has no access to the
>>>                 resolved method, or does
>>>                 ? ? ? ? // 'invokestatic' on a hidden class which
>>>                 cannot be resolved by name.
>>>                 ? ? ? ? // Instead, we need to pass the live
>>>                 implementation method handle to
>>>                 ? ? ? ? // the proxy class to invoke directly.
>>>                 (javac prefers to avoid this
>>>                 ? ? ? ? // situation by generating bridges in the
>>>                 target class)
>>>                 ? ? ? ? useImplMethodHandle =
>>>                 (Modifier.isProtected(implInfo.getModifiers()) &&
>>>                 ?!VerifyAccess.isSamePackage(targetClass,
>>>                 implInfo.getDeclaringClass())) ||
>>>                 ?implKind == MethodHandleInfo.REF_invokeSpecial ||
>>>                 ?implKind == MethodHandleInfo.REF_invokeStatic &&
>>>                 implClass.isHidden();
>>>
>>>                 In premain lambda proxy classes get included in the
>>>                 AOT cache as a result of indy resolution and that
>>>                 mechanism doesn't have this kind of check.
>>>
>>>                 3. For the null classData problem mentioned above, I
>>>                 tried to fix it by storing classData in the scratch
>>>                 mirror using the following patch:
>>>
>>>                 diff --git
>>>                 a/src/hotspot/share/classfile/javaClasses.cpp
>>>                 b/src/hotspot/share/classfile/javaClasses.cpp
>>>                 index bd8141adbcc..41766e98093 100644
>>>                 --- a/src/hotspot/share/classfile/javaClasses.cpp
>>>                 +++ b/src/hotspot/share/classfile/javaClasses.cpp
>>>                 @@ -1094,9 +1094,9 @@ void
>>>                 java_lang_Class::create_mirror(Klass* k, Handle
>>>                 class_loader,
>>>                 ? ? ?}
>>>                 ? ? ?if (CDSConfig::is_dumping_heap()) {
>>>                 ? ? ? ?if (CDSConfig::is_dumping_protection_domains()) {
>>>                 - ? ? ? ?create_scratch_mirror(k, protection_domain,
>>>                 CHECK);
>>>                 + ? ? ? ?create_scratch_mirror(k, protection_domain,
>>>                 classData, CHECK);
>>>                 ? ? ? ?} else {
>>>                 - ? ? ? ?create_scratch_mirror(k, Handle() /* null
>>>                 protection_domain*/, CHECK);
>>>                 + ? ? ? ?create_scratch_mirror(k, Handle() /* null
>>>                 protection_domain*/, classData, CHECK);
>>>                 ? ? ? ?}
>>>                 ? ? ?}
>>>                 ? ?} else {
>>>                 @@ -1117,7 +1117,7 @@ void
>>>                 java_lang_Class::create_mirror(Klass* k, Handle
>>>                 class_loader,
>>>                 ?// Note: we archive the "scratch mirror" instead of
>>>                 k->java_mirror(), because the
>>>                 ?// latter may contain dumptime-specific information
>>>                 that cannot be archived
>>>                 ?// (e.g., ClassLoaderData*, or static fields that
>>>                 are modified by Java code execution).
>>>                 -void java_lang_Class::create_scratch_mirror(Klass*
>>>                 k, Handle protection_domain, TRAPS) {
>>>                 +void java_lang_Class::create_scratch_mirror(Klass*
>>>                 k, Handle protection_domain, Handle classData, TRAPS) {
>>>                 ? ?if (k->class_loader() != nullptr &&
>>>                 ? ? ? ?k->class_loader() !=
>>>                 SystemDictionary::java_platform_loader() &&
>>>                 ? ? ? ?k->class_loader() !=
>>>                 SystemDictionary::java_system_loader()) {
>>>                 @@ -1125,9 +1125,11 @@ void
>>>                 java_lang_Class::create_scratch_mirror(Klass* k,
>>>                 Handle protection_domain,
>>>                 ? ? ?return;
>>>                 ? ?}
>>>
>>>                 - ?Handle classData; // set to null. Will be
>>>                 reinitialized at runtime
>>>                 + ?//Handle classData; // set to null. Will be
>>>                 reinitialized at runtime
>>>                 ? ?Handle mirror;
>>>                 ? ?Handle comp_mirror;
>>>                 ? ?allocate_mirror(k, /*is_scratch=*/true,
>>>                 protection_domain, classData, mirror, comp_mirror,
>>>                 CHECK);
>>>
>>>                 ? ?if (comp_mirror() != nullptr) {
>>>                 diff --git
>>>                 a/src/hotspot/share/classfile/javaClasses.hpp
>>>                 b/src/hotspot/share/classfile/javaClasses.hpp
>>>                 index bc49a0861a7..7ec2a2556dd 100644
>>>                 --- a/src/hotspot/share/classfile/javaClasses.hpp
>>>                 +++ b/src/hotspot/share/classfile/javaClasses.hpp
>>>                 @@ -263,7 +263,7 @@ class java_lang_Class : AllStatic {
>>>
>>>                 ? ?// Archiving
>>>                 ? ?static void serialize_offsets(SerializeClosure*
>>>                 f) NOT_CDS_RETURN;
>>>                 - ?static void create_scratch_mirror(Klass* k,
>>>                 Handle protection_domain, TRAPS)
>>>                 NOT_CDS_JAVA_HEAP_RETURN;
>>>                 + ?static void create_scratch_mirror(Klass* k,
>>>                 Handle protection_domain, Handle classData, TRAPS)
>>>                 NOT_CDS_JAVA_HEAP_RETURN;
>>>                 ? ?static bool restore_archived_mirror(Klass *k,
>>>                 Handle class_loader, Handle module,
>>>                 ? ? ?Handle protection_domain,
>>>                 ? ? ?TRAPS) NOT_CDS_JAVA_HEAP_RETURN_(false);
>>>
>>>                 But this resulted in a different exception:
>>>
>>>                 Exception in thread "main"
>>>                 java.lang.ExceptionInInitializerError
>>>                 at com.redhat.leyden.Main.main(Main.java:7)
>>>                 Caused by:
>>>                 java.lang.invoke.WrongMethodTypeException: handle's
>>>                 method type (WildFlyElytronBaseProvider,Service)void
>>>                 but found (WildFlyElytronBaseProvider,Service)void
>>>                 at
>>>                 java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>>>                 at
>>>                 java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>>>                 at
>>>                 java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
>>>                 at
>>>                 org.wildfly.security.WildFlyElytronBaseProvider$$Lambda/0x80000000c.accept(Unknown
>>>                 Source)
>>>                 at
>>>                 org.wildfly.security.WildFlyElytronBaseProvider.putMakedPasswordImplementations(WildFlyElytronBaseProvider.java:112)
>>>                 at
>>>                 org.wildfly.security.WildFlyElytronBaseProvider.putPasswordImplementations(WildFlyElytronBaseProvider.java:107)
>>>                 at
>>>                 org.wildfly.security.password.WildFlyElytronPasswordProvider.<init>(WildFlyElytronPasswordProvider.java:43)
>>>                 at
>>>                 org.wildfly.security.password.WildFlyElytronPasswordProvider.<clinit>(WildFlyElytronPasswordProvider.java:36)
>>>                 ... 1 more
>>>
>>>                 The exception message is strange because the
>>>                 handle's method type and the expected type are both
>>>                 symbolically the same.
>>>                 I am debugging this exception at the moment.
>>>                 Thanks,
>>>                 - Ashutosh Mehra
>>>
>>>
>>>                 On Wed, Sep 11, 2024 at 6:03?AM Andrew Dinn
>>>                 <adinn at redhat.com> wrote:
>>>
>>>                     Oops, sorry, I debugged this a few days ago!
>>>                     Correction to a few details:
>>>
>>>                     On 11/09/2024 10:39, Andrew Dinn wrote:
>>>                     > A crash due to an NPE was observed in the
>>>                     Infinispan (Data Grid) server
>>>                     > app when deployed using the Leyden EA. The
>>>                     crash still manifests with
>>>                     > the latest premain code. The crash happens
>>>                     below an application call
>>>                     > which employs a method reference as argument
>>>                     >
>>>                     >
>>>                     putMakedPasswordImplementations(this::putService,
>>>                     this);
>>>
>>>                     The called method in turn calls consumer.accept
>>>
>>>                     ? ? ? ? ? ? ?consumer.accept(new Service(provider,
>>>                     PASSWORD_FACTORY_TYPE, algorithm,
>>>                     "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>>                     emptyList,
>>>                     emptyMap));
>>>
>>>                     which enters enters
>>>                     MethodHandleNative::linkDynamicConstant()
>>>
>>>                     > Debugging shows that the call to
>>>                     linkDynamicConstant() returns null.
>>>                     >
>>>                     > A simple reproducer for the problem is
>>>                     available as a maven project on
>>>                     > github:
>>>                     >
>>>                     >
>>>                     https://github.com/tristantarrant/elytron-leyden
>>>                     <https://urldefense.com/v3/__https://github.com/tristantarrant/elytron-leyden__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZaZr1akQ$>
>>>                     >
>>>                     > The ReadMe provides an explanation of how to
>>>                     reproduce the problem. I
>>>                     > did so and the debugged to find out some of
>>>                     the details of what is
>>>                     > happening (see below) but did not fully
>>>                     clarify the problem. Help from
>>>                     > someone more conversant with the ins and outs
>>>                     of method handle
>>>                     > bootstraps in premain would be welcome.
>>>                     Details follow.
>>>                     >
>>>                     > regards,
>>>                     >
>>>                     >
>>>                     > Andrew Dinn
>>>                     > -----------
>>>                     >
>>>                     > I downloaded the git repo and attached the
>>>                     Java sources using Maven command
>>>                     >
>>>                     >? ? $ mvn dependency:sources
>>>                     >
>>>                     > Having manifested the crash by following the
>>>                     instructions in the README
>>>                     > I reran the leyden JVM under gdb using the
>>>                     following commands to enable
>>>                     > Java debugging
>>>                     >
>>>                     > $ gdb ${LEYDEN_HOME}/bin/java
>>>                     > (gdb) cd /path/to/mvn/project
>>>                     > (gdb) run
>>>                     >
>>>                     -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
>>>
>>>                     > -classpath
>>>                     >
>>>                     /home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/2.5.1.
>>>                     <https://urldefense.com/v3/__http://2.5.1.__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhauJ-RjcQ$>Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar
>>>                     -XX:CacheDataStore=elytron.aot
>>>                     com.redhat.leyden.Main
>>>                     >
>>>                     > The problem manifests at
>>>                     WildflyElytronBaseProvider.java:112 in method
>>>                     >
>>>                     WildflyElytronBaseProvider::putMakedPasswordImplementations
>>>
>>>                     ? ? ?static void
>>>                     putMakedPasswordImplementations(Consumer<Service>
>>>                     consumer, Provider provider) {
>>>                     ? ? ? ? ?for (String algorithm :
>>>                     MASKED_ALGORITHMS) {
>>>                     ? ? ? ? ? ? ?consumer.accept(new Service(provider,
>>>                     PASSWORD_FACTORY_TYPE, algorithm,
>>>                     "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>>                     emptyList,
>>>                     emptyMap)); <== NPE under this call
>>>                     ? ? ? ? ?}
>>>
>>>
>>>                     > The source code for this method can be found
>>>                     in the following source jar
>>>                     >
>>>                     >
>>>                     >
>>>                     ${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar
>>>                     >
>>>                     > (where M2_REPO will normally be ~/.m2/repository)
>>>                     >
>>>                     > Stepping into accept eventually enters
>>>                     MethodHandleNative::linkDynamicConstant
>>>                     > which in turn enters into
>>>                     ConstantBootstraps.makeConstant(). The caller
>>>                     > Class at this point is a lambda class which
>>>                     prints as
>>>                     >
>>>                     org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c
>>>                     >
>>>                     > Several steps further the code enters
>>>                     BootstrapMethodInvoker::invoke
>>>                     > (below the app method call but via 3 hidden
>>>                     frames) with bootstrapMethod
>>>                     > bound to a DirectMethodHandle. After several
>>>                     more steps this enters
>>>                     > DirectMethodHandle$Holder.invokeStatic which
>>>                     in turn calls
>>>                     > MethodHandles::classData(Lookup,String,Class).
>>>                     >
>>>                     > At this point caller is a MethodHandleLookup
>>>                     for the lambda class
>>>                     > Lambda/0x800000000c mentioned above. The
>>>                     following call
>>>                     >
>>>                     >? ???????? Object classdata =
>>>                     classData(caller.lookupClass());
>>>                     >
>>>                     > returns null to
>>>                     DirectMethodHandle$Holder.invokeStatic which
>>>                     pops the
>>>                     > same result back out to
>>>                     BootstrapMethodInvoker::invoke at line 90
>>>                     >
>>>                     >? ??????????????? if (type instanceof Class<?> c) {
>>>                     >? ??????????????????? result =
>>>                     bootstrapMethod.invoke(caller, name, c);
>>>                     > <== null
>>>                     >
>>>                     > This null result pops back out as the value
>>>                     for the call to
>>>                     > BootstrapMethodInvoker.invoke(),
>>>                     ConstantBootstraps.makeConstant() and
>>>                     > MethodHandleNative::linkDynamicConstant().
>>>                     >
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240919/a1f87343/attachment.htm>

From macarte at openjdk.org  Thu Sep 19 22:25:20 2024
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 19 Sep 2024 22:25:20 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v10]
In-Reply-To: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
Message-ID: <vhDl3dIKAqKXxNft6BjKVblzbwFlF2Nvp0stOtYGhxo=.21cfe2d5-e0a8-4eb5-bb3b-7e16256b0d75@github.com>

> AOT training can be ended using either
> 
> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
> - jcmd <pid> AOT.end_training
> 
> supports arm64 and x64
> 
> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
> 
> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  remove trailing spaces

-------------

Changes:
  - all: https://git.openjdk.org/leyden/pull/21/files
  - new: https://git.openjdk.org/leyden/pull/21/files/9f3a4c3c..63d60ae9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=09
 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=21&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/leyden/pull/21.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/21/head:pull/21

PR: https://git.openjdk.org/leyden/pull/21

From ioi.lam at oracle.com  Fri Sep 20 00:51:05 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Thu, 19 Sep 2024 17:51:05 -0700
Subject: premain: Crash in Infinispan server code caused by NPE under
 MethodHandleNative::linkDynamicConstant
In-Reply-To: <45e62b78-bbde-4ba5-8b20-77125d14b908@oracle.com>
References: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
 <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>
 <CAKt0pySztvwsadtrqjai6XwakAWq_v_o8men4aopLo4X-0azyQ@mail.gmail.com>
 <CAKt0pyQ44E+npyUW35Zhxg+PfBgF2yuNgS61gj1GGj=aLGTJXw@mail.gmail.com>
 <CAKt0pyT48uPH6rUL7bEJ2rtWqNdNL34DWBJ2SDaHwYfVxURnQw@mail.gmail.com>
 <0d22d580-39a1-4105-a50e-8a74a555090d@oracle.com>
 <CAKt0pyRYBNtkLzVoAfDHWE=4e+9efZFb+xKYZv-d3LpDAU4qZg@mail.gmail.com>
 <da797fe2-137c-4fc7-a67c-3b595c0c63f2@oracle.com>
 <CAKt0pyRj8_mDiH58v10sqXNHA4iHja6-7D9N_S2VW9rhESPcTw@mail.gmail.com>
 <45e62b78-bbde-4ba5-8b20-77125d14b908@oracle.com>
Message-ID: <4dc70b95-f014-44f1-acfb-027c8e28e81d@oracle.com>

Upon further investigation, it seems a simple patch might fix the 
problem with classData.

I tested with 
test/hotspot/jtreg/runtime/cds/appcds/LambdaWithUseImplMethodHandle.java 
by running jtreg with -javaoptions:-XX:+AOTClassLinking
Without the patch, I'd get a NullPointerException. With the patch, the 
test passes.

It looks like classData is not treated as a static field of the class, 
but rather an instance field in the mirror. So classData wasn't copied 
by the loop in HeapShared::copy_preinitialized_mirror().

Ashutosh, could you try it this fixes the crash on your side?

Thanks

- Ioi

diff --git a/src/hotspot/share/cds/heapShared.cpp 
b/src/hotspot/share/cds/heapShared.cpp
index 0e70778f057..62cf142f67a 100644
--- a/src/hotspot/share/cds/heapShared.cpp
+++ b/src/hotspot/share/cds/heapShared.cpp
@@ -634,6 +634,8 @@ void HeapShared::copy_preinitialized_mirror(Klass* 
orig_k, oop orig_mirror, oop
 ???? }
 ?? }

+? java_lang_Class::set_class_data(m, 
java_lang_Class::class_data(orig_mirror));
+
 ?? // Class::reflectData use SoftReference, which cannot be archived. 
Set it
 ?? // to null and it will be recreated at runtime.
 ?? java_lang_Class::set_reflection_data(m, nullptr);



On 9/19/24 12:51 PM, ioi.lam at oracle.com wrote:
>
>
> On 9/19/24 7:44 AM, Ashutosh Mehra wrote:
>>
>>     As I am cleaning up the code for upstreaming to mainline, I am
>>     going add an equivalent check in the C code to filter out these
>>     indy call sites, so they won't be resolved at all during the
>>     assembly phase. Otherwise, I will run into problems described in
>>     https://bugs.openjdk.org/browse/JDK-8290417
>>
>>
>> Thanks for the link to the bug. The scenario described in that bug is 
>> exactly the same as the Infinispan case.
>> So if we filter out such cases during indy resolution then it should 
>> resolve the Infinispan issue as well.
>>
>> A basic question: why?can't CDS handle the lambda proxy class 
>> generated in useImplMethodHandle?mode?
>>
> If I remember correctly, it has to do with the shape of dynamically 
> generated bytecode:
>
> ? public void accept(java.lang.Object);
> ??? Code:
> ?????? 0: ldc #28 // Dynamic #0:_:Ljava/lang/invoke/MethodHandle;
> ?????? 2: aload_0
> ?????? 3: getfield #15 // Field arg$1:LTester;
> ?????? 6: aload_1
> ?????? 7: checkcast #30 // class java/lang/String
> ????? 10: invokevirtual #36 // Method 
> java/lang/invoke/MethodHandle.invokeExact:(LTester;Ljava/lang/String;)V
> ????? 13: return
>
> The result of the "ldc" was not symbolically encoded in the generated 
> class (as the generated class has no permission to access that 
> method). So the MethodHandle is stored as a binary object in the 
> mirror of this generated class (with the java.lang.Class::classData 
> field).
>
> Plain CDS doesn't archive class mirrors, so the classData will be lost.
>
> With JEP 483, we should be able to preserve the classData, so I am not 
> sure why the useImplMethodHandle case is still failing. My plan is to 
> filter these out for now, but I will get back to it later when I have 
> more time.
>
> Thanks
>
> - Ioi
>
>
>
>
>> Thanks,
>> - Ashutosh Mehra
>>
>>
>> On Thu, Sep 19, 2024 at 1:45?AM <ioi.lam at oracle.com> wrote:
>>
>>     Hi Ashutosh,
>>
>>     I have some update:
>>
>>     The original crash was caused by the "useImplMethodHandle" code
>>     in InnerClassLambdaMetafactory.java:
>>
>>     ??????? // If the target class invokes a protected method
>>     inherited from a
>>     ??????? // superclass in a different package, or does
>>     'invokespecial', the
>>     ??????? // lambda class has no access to the resolved method, or does
>>     ??????? // 'invokestatic' on a hidden class which cannot be
>>     resolved by name.
>>     ??????? // Instead, we need to pass the live implementation
>>     method handle to
>>     ??????? // the proxy class to invoke directly. (javac prefers to
>>     avoid this
>>     ??????? // situation by generating bridges in the target class)
>>     ??????? useImplMethodHandle =
>>     (Modifier.isProtected(implInfo.getModifiers()) &&
>>     !VerifyAccess.isSamePackage(targetClass,
>>     implInfo.getDeclaringClass())) ||
>>     ?????????????????????????????? implKind ==
>>     MethodHandleInfo.REF_invokeSpecial ||
>>     ?????????????????????????????? implKind ==
>>     MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>>
>>     As I am cleaning up the code for upstreaming to mainline, I am
>>     going add an equivalent check in the C code to filter out these
>>     indy call sites, so they won't be resolved at all during the
>>     assembly phase. Otherwise, I will run into problems described in
>>     https://bugs.openjdk.org/browse/JDK-8290417
>>
>>     Once I get the filtering code working, I will integrate it back
>>     to premain.
>>
>>     >I am wondering if we can workaround class circularity issues by
>>     recording class initialization order
>>     >during training run and use that to guide the initialization
>>     during assembly phase.
>>
>>     In the production run we take different paths than the training run
>>
>>     (1) some classes are aot-initialized (especially the enums)
>>     (2) some classes make special CDS calls
>>
>>     so I am not sure if it's possible to get the same initialization
>>     order as in the training run (or assembly phase).
>>
>>     (more below)
>>
>>     On 9/18/24 9:10 AM, Ashutosh Mehra wrote:
>>>     Hi Ioi,
>>>
>>>         I was having a similar circularity issue (but in production
>>>         time) and I just added enough classes to make the NPE go away.
>>>
>>>     I am wondering if you have a test case that reproduces the NPE
>>>     which prompted you to add these classes:
>>>
>>>     https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp#L65-L78
>>>     <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp*L65-L78__;Iw!!ACWV5N9M2RV99hQ!NYvqLbb_Ib2kSdm2fcYVLGby-AiB2TG7KtC1HQHVKLiM-_kRb5mOt8krV5IZfReaYZ0MPadDfa08hQ$>
>>>
>>>     I commented this code and ran the tests under premain but didn't
>>>     hit?the NPE.
>>>
>>     I forgot what the problem was, but it happened for very simple cases.
>>
>>     Thanks
>>
>>     - Ioi
>>
>>
>>>     Thanks,
>>>     - Ashutosh Mehra
>>>
>>>
>>>     On Tue, Sep 17, 2024 at 1:11?AM <ioi.lam at oracle.com> wrote:
>>>
>>>         Hi Ashutosh,
>>>
>>>         So this looks like a potential bug (or feature) in the core
>>>         lib code. When CDS forcefully initializes a class in an
>>>         unexpected (or untested) order, the "initialization soup" fails.
>>>
>>>         Perhaps a work-around would be to make some harmless calls
>>>         at the place where CDS was calling into
>>>         MethodType.createArchivedObjects(). E.g., do something like
>>>         this:
>>>
>>>         +??? if (CDSConfig::is_dumping_invokedynamic()) {
>>>         +?????? // call into Java:
>>>         jdk.internal.misc::warmupInvokeDynamic();
>>>         +?? }
>>>         ??? // Rewrite and link classes
>>>         ??? log_info(cds)("Rewriting and linking classes ...");
>>>
>>>         Maybe you can add a new Lambda expressions, MethodHandle
>>>         invocations, etc, that would hopefully cause
>>>         PrimitiveClassDescImpl and friends to be initialized in
>>>         their natural order.
>>>
>>>         Or call class.forName("java.lang.constant.ConstantDescs") ??
>>>
>>>         BTW, you can see my comments in
>>>         AOTClassInitializer::is_forced_preinit_class():
>>>
>>>         ??? // TODO:
>>>         ??? // This is needed since JDK-8338532. Without this, when
>>>         ??? // archived heap objects are used, the class init order
>>>         is not
>>>         ??? // expected by the jdk/internal/constant bootstrap code
>>>         and we
>>>         ??? // will get a null pointer exception.
>>>         ??? //
>>>         ??? // When bootstraping has intricated/fragile order, it's
>>>         probably
>>>         ??? // better to archive all related classes in an
>>>         initialized state
>>>         ??? // (i.e., take a snapshot). The existing approach in
>>>         ??? // heapShared::resolve_or_init_classes_for_subgraph_of()
>>>         won't work.
>>>         "jdk/internal/constant/PrimitiveClassDescImpl",
>>>         "jdk/internal/constant/ReferenceClassDescImpl",
>>>         ??? "java/lang/constant/ConstantDescs",
>>>         ??? "sun/invoke/util/Wrapper",
>>>
>>>         I was having a similar circularity issue (but in production
>>>         time) and I just added enough classes to make the NPE go
>>>         away. For your test case, if you manage to fix in in the
>>>         assembly run but run into NPE in production run, you might
>>>         need to add more classes to this list. Yes, it's a hack :-(
>>>
>>>
>>>         Thanks
>>>
>>>         - Ioi
>>>
>>>         On 9/13/24 7:05 PM, Ashutosh Mehra wrote:
>>>>         This is turning out to be a real example of class
>>>>         initialization soup!
>>>>         As mentioned during the meeting, I am getting NPE in the
>>>>         assembly phase when testing the patch [0] that I proposed
>>>>         in my earlier mail
>>>>         using a test case inspired by the Infinispan code.
>>>>         NPE occurs when running the class initializer for
>>>>         PrimitiveClassDescImpl
>>>>         Interestingly, PrimitiveClassDescImpl?is "forcefully"
>>>>         initialized by MetaspaceShared::link_shared_classes().
>>>>
>>>>         I couldn't get a stack trace so I relied on exception logs
>>>>         (using -Xlog:exceptions=trace) to find the cause which
>>>>         indicate following frames on the stack:
>>>>
>>>>         [0]
>>>>         jdk/internal/constant/MethodTypeDescImpl::validateArgument(Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/ClassDesc;?@
>>>>         bci 1
>>>>         [1]
>>>>         jdk/internal/constant/MethodTypeDescImpl::ofTrusted(Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljdk/internal/constant/MethodTypeDescImpl;?@
>>>>         bci 27
>>>>         [2]
>>>>         java/lang/constant/ConstantDescs::ofConstantBootstrap(Ljava/lang/constant/ClassDesc;Ljava/lang/String;Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/DirectMethodHandleDesc;?@
>>>>         bci 47
>>>>         [3] java/lang/constant/ConstantDescs::<clinit>?@ bci 664
>>>>         [4]
>>>>         jdk/internal/constant/PrimitiveClassDescImpl::<init>(Ljava/lang/String;)V?@
>>>>         bci 1
>>>>         [5]
>>>>         jdk/internal/constant/PrimitiveClassDescImpl::<clinit>(Ljava/lang/String;)V?@
>>>>         bci 6
>>>>
>>>>         Notice?that invocation of PrimitiveClassDescImpl::<clinit>
>>>>         results in initialization of ConstantDescs?class (see frame 3).
>>>>         ConstantDescs::<clinit>?@ 664 corresponds to following java
>>>>         code:
>>>>
>>>>         ? ? public static final DirectMethodHandleDesc
>>>>         BSM_CLASS_DATA_AT
>>>>         ? = ofConstantBootstrap(CD_MethodHandles, "classDataAt",
>>>>         ? ? ? ? ? ? CD_Object, CD_int);
>>>>
>>>>         The last parameter CD_int is initialized as:
>>>>
>>>>         ? ? public static final ClassDesc CD_int =
>>>>         PrimitiveClassDescImpl.CD_int;
>>>>
>>>>         So, its value is obtained from
>>>>         PrimitiveClassDescImpl.CD_int?which hasn't been initialized
>>>>         properly yet. As a result ConstantDescs::CD_int is
>>>>         assigned?null which results in
>>>>         MethodTypeDescImpl::validateArgument throwing NPE later.
>>>>         There is a clear class initialization circularity involving
>>>>         PrimitiveClassDescImpl and ConstantDescs, and the result
>>>>         depends on which class gets initialized first.
>>>>
>>>>         Without my patch this issue is not seen because
>>>>         PrimitiveClassDescImpl has already been initialized by the
>>>>         time MetaspaceShared::link_shared_classes()?is called.
>>>>         Its initialization is triggered by the call to
>>>>         MethodType::createArchivedObjects().
>>>>         It also explains why my patch introduced this issue because
>>>>         it effectively moved the call to
>>>>         MethodType::createArchivedObjects() after
>>>>         MetaspaceShared::link_shared_classes().
>>>>
>>>>         [0]
>>>>         https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>>>         <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>>>
>>>>         Thanks,
>>>>         - Ashutosh Mehra
>>>>
>>>>
>>>>         On Wed, Sep 11, 2024 at 3:12?PM Ashutosh Mehra
>>>>         <asmehra at redhat.com> wrote:
>>>>
>>>>             Regarding the WrongMethodTypeException that I mentioned
>>>>             in my previous email (see pt 3),
>>>>             this exception happens when lambda proxy class attempts
>>>>             to invoke the MethodHandle it obtained from the classData:
>>>>
>>>>             ? public void accept(java.lang.Object);
>>>>             ? ? descriptor: (Ljava/lang/Object;)V
>>>>             ? ? flags: (0x0001) ACC_PUBLIC
>>>>             ? ? Code:
>>>>             ? ? ? stack=3, locals=2, args_size=2
>>>>             ? ? ? ? ?0: ldc ? ? ? ? ? #26 ? ? ? ? // Dynamic
>>>>             #0:_:Ljava/lang/invoke/MethodHandle;
>>>>             ? ? ? ? ?2: aload_0
>>>>             ? ? ? ? ?3: getfield ? ? ?#13 ? ? ? ? // Field
>>>>             arg$1:Lorg/wildfly/security/WildFlyElytronBaseProvider;
>>>>             ? ? ? ? ?6: aload_1
>>>>             ? ? ? ? ?7: checkcast ? ? #28 ? ? ? ? // class
>>>>             java/security/Provider$Service
>>>>             ? ? ? ? 10: invokevirtual #34 ? ? ? ? // Method
>>>>             java/lang/invoke/MethodHandle.invokeExact:(Lorg/wildfly/security/WildFlyElytronBaseProvider;Ljava/security/Provider$Service;)V
>>>>             ? ? ? ? 13: return
>>>>
>>>>             The scenario is during the assembly phase as part of
>>>>             the indy resolution the MethodHandle for which the
>>>>             exception is thrown gets created.
>>>>             Normally MethodHandle's type gets added in
>>>>             MethodType::internTable but by the time indy resolution
>>>>             happens, JVM has already taken
>>>>             snapshot of the MethodType::internTable through an
>>>>             upcall to MethodType::createArchivedObjects().
>>>>             As a result the AOTCache ends up with the MethodType
>>>>             object which is not in AOTHolder.archivedMethodTypes.
>>>>
>>>>             During the production run, when the jvm invokes the
>>>>             MethodHandle, it searches for the MethodType
>>>>             corresponding to the signature passed at the callsite.
>>>>             As expected, it fails to find it in the
>>>>             AOTHolder.archivedMethodTypes, so it creates a new
>>>>             instance of the MethodType.
>>>>             But Invokers.checkExactType() relies on the
>>>>             MethodHandle's?type to be the same object as the
>>>>             MethodType object passed as parameter.
>>>>
>>>>             ? ? static void checkExactType(MethodHandle mhM,
>>>>             MethodType expected) {
>>>>             MethodType targetType = mh.type();
>>>>             ? ? ? ? if (targetType != expected)
>>>>             ? ? ? ? ? ? throw
>>>>             newWrongMethodTypeException(targetType, expected);
>>>>             ? ? }
>>>>
>>>>             Hence, it throws WrongMethodTypeException?though the
>>>>             two MT objects have the same signature.
>>>>
>>>>             To handle this scenario, I changed the order of indy
>>>>             resolution and upcall to
>>>>             MethodType::createArchivedObjects()?as:
>>>>
>>>>             diff --git a/src/hotspot/share/cds/metaspaceShared.cpp
>>>>             b/src/hotspot/share/cds/metaspaceShared.cpp
>>>>             index df4bcadefa3..457716cac5b 100644
>>>>             --- a/src/hotspot/share/cds/metaspaceShared.cpp
>>>>             +++ b/src/hotspot/share/cds/metaspaceShared.cpp
>>>>             @@ -751,6 +751,20 @@ void
>>>>             MetaspaceShared::link_shared_classes(bool jcmd_request,
>>>>             TRAPS) {
>>>>             ? ?if (CDSConfig::is_dumping_final_static_archive()) {
>>>>             ?FinalImageRecipes::apply_recipes(CHECK);
>>>>             ? ?}
>>>>             +
>>>>             +#if INCLUDE_CDS_JAVA_HEAP
>>>>             + ?if (CDSConfig::is_dumping_invokedynamic()) {
>>>>             + ? ?// This makes sure that the MethodType and
>>>>             MethodTypeForm tables won't be updated
>>>>             + ? ?// concurrently when we are saving their contents
>>>>             into a side table.
>>>>             + ?assert(CDSConfig::allow_only_single_java_thread(),
>>>>             "Required");
>>>>             +
>>>>             + ? ?JavaValue result(T_VOID);
>>>>             + ?JavaCalls::call_static(&result,
>>>>             vmClasses::MethodType_klass(),
>>>>             + vmSymbols::createArchivedObjects(),
>>>>             + vmSymbols::void_method_signature(),
>>>>             + ? ? ? ? ? ? ? ? ? ? ? ? ? CHECK);
>>>>             + ?}
>>>>             +#endif
>>>>             ?}
>>>>             Note that indy resolution happens as part of
>>>>             FinalImageRecipes::apply_recipes(CHECK) which is now
>>>>             invoked before the upcall to createArchivedObjects().
>>>>             With this change I am able to run the application
>>>>             without any exceptions.
>>>>             My complete patch can be seen here:
>>>>             https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>>>             <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>>>             I will do more testing with this patch.
>>>>
>>>>             @Ioi Lam <mailto:ioi.lam at oracle.com>?do you have any
>>>>             feedback on this patch.
>>>>
>>>>             Thanks,
>>>>             - Ashutosh Mehra
>>>>
>>>>
>>>>
>>>>             On Wed, Sep 11, 2024 at 10:14?AM Ashutosh Mehra
>>>>             <asmehra at redhat.com> wrote:
>>>>
>>>>                 Hi Andrew,
>>>>                 Thanks for sharing the initial investigation.
>>>>                 I have been looking into this and have a few of
>>>>                 things to add to your analysis:
>>>>
>>>>                 1.? As you mentioned the classData for the lambda
>>>>                 class?WildFlyElytronBaseProvider$$Lambda is null.
>>>>                 The classData is stored in the mirror object of the
>>>>                 InstanceKlass when the class is defined
>>>>                 through?JVM_LookupDefineClass.
>>>>                 However, when we create the scratch mirror object
>>>>                 (which get stored in the AOT cache) the classData
>>>>                 is not populated.
>>>>                 See
>>>>                 https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp#L1128-L1131
>>>>                 <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp*L1128-L1131__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhbKjzG3gw$>
>>>>
>>>>                 ? Handle classData; // set to null. Will be
>>>>                 reinitialized at runtime
>>>>                 ? Handle mirror;
>>>>                 ? Handle comp_mirror;
>>>>                 ? allocate_mirror(k, /*is_scratch=*/true,
>>>>                 protection_domain, classData, mirror, comp_mirror,
>>>>                 CHECK);
>>>>
>>>>                 So this explains why the call to
>>>>                 classData(caller.lookupClass())returned null.
>>>>
>>>>                 2. In the mainline there is a check
>>>>                 in?InnerClassLambdaMetafactory.java for the
>>>>                 particular code pattern used by the application.
>>>>                 If this code pattern is found then the lambda proxy
>>>>                 class is not included in the CDS archive.
>>>>                 See
>>>>                 https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L163-L170
>>>>                 <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L163-L170__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZl2S9tQg$>
>>>>                 and
>>>>                 https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L246
>>>>                 <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L246__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhYsI3Xx0g$>
>>>>
>>>>                 // If the target class invokes a protected method
>>>>                 inherited from a
>>>>                 ? ? ? ? // superclass in a different package, or
>>>>                 does 'invokespecial', the
>>>>                 ? ? ? ? // lambda class has no access to the
>>>>                 resolved method, or does
>>>>                 ? ? ? ? // 'invokestatic' on a hidden class which
>>>>                 cannot be resolved by name.
>>>>                 ? ? ? ? // Instead, we need to pass the live
>>>>                 implementation method handle to
>>>>                 ? ? ? ? // the proxy class to invoke directly.
>>>>                 (javac prefers to avoid this
>>>>                 ? ? ? ? // situation by generating bridges in the
>>>>                 target class)
>>>>                 ? ? ? ? useImplMethodHandle =
>>>>                 (Modifier.isProtected(implInfo.getModifiers()) &&
>>>>                 ?!VerifyAccess.isSamePackage(targetClass,
>>>>                 implInfo.getDeclaringClass())) ||
>>>>                 ?implKind == MethodHandleInfo.REF_invokeSpecial ||
>>>>                 ?implKind == MethodHandleInfo.REF_invokeStatic &&
>>>>                 implClass.isHidden();
>>>>
>>>>                 In premain lambda proxy classes get included in the
>>>>                 AOT cache as a result of indy resolution and that
>>>>                 mechanism doesn't have this kind of check.
>>>>
>>>>                 3. For the null classData problem mentioned above,
>>>>                 I tried to fix it by storing classData in the
>>>>                 scratch mirror using the following patch:
>>>>
>>>>                 diff --git
>>>>                 a/src/hotspot/share/classfile/javaClasses.cpp
>>>>                 b/src/hotspot/share/classfile/javaClasses.cpp
>>>>                 index bd8141adbcc..41766e98093 100644
>>>>                 --- a/src/hotspot/share/classfile/javaClasses.cpp
>>>>                 +++ b/src/hotspot/share/classfile/javaClasses.cpp
>>>>                 @@ -1094,9 +1094,9 @@ void
>>>>                 java_lang_Class::create_mirror(Klass* k, Handle
>>>>                 class_loader,
>>>>                 ? ? ?}
>>>>                 ? ? ?if (CDSConfig::is_dumping_heap()) {
>>>>                 ? ? ? ?if
>>>>                 (CDSConfig::is_dumping_protection_domains()) {
>>>>                 - ?create_scratch_mirror(k, protection_domain, CHECK);
>>>>                 + ?create_scratch_mirror(k, protection_domain,
>>>>                 classData, CHECK);
>>>>                 ? ? ? ?} else {
>>>>                 - ?create_scratch_mirror(k, Handle() /* null
>>>>                 protection_domain*/, CHECK);
>>>>                 + ?create_scratch_mirror(k, Handle() /* null
>>>>                 protection_domain*/, classData, CHECK);
>>>>                 ? ? ? ?}
>>>>                 ? ? ?}
>>>>                 ? ?} else {
>>>>                 @@ -1117,7 +1117,7 @@ void
>>>>                 java_lang_Class::create_mirror(Klass* k, Handle
>>>>                 class_loader,
>>>>                 ?// Note: we archive the "scratch mirror" instead
>>>>                 of k->java_mirror(), because the
>>>>                 ?// latter may contain dumptime-specific
>>>>                 information that cannot be archived
>>>>                 ?// (e.g., ClassLoaderData*, or static fields that
>>>>                 are modified by Java code execution).
>>>>                 -void java_lang_Class::create_scratch_mirror(Klass*
>>>>                 k, Handle protection_domain, TRAPS) {
>>>>                 +void java_lang_Class::create_scratch_mirror(Klass*
>>>>                 k, Handle protection_domain, Handle classData, TRAPS) {
>>>>                 ? ?if (k->class_loader() != nullptr &&
>>>>                 ? ? ? ?k->class_loader() !=
>>>>                 SystemDictionary::java_platform_loader() &&
>>>>                 ? ? ? ?k->class_loader() !=
>>>>                 SystemDictionary::java_system_loader()) {
>>>>                 @@ -1125,9 +1125,11 @@ void
>>>>                 java_lang_Class::create_scratch_mirror(Klass* k,
>>>>                 Handle protection_domain,
>>>>                 ? ? ?return;
>>>>                 ? ?}
>>>>
>>>>                 - ?Handle classData; // set to null. Will be
>>>>                 reinitialized at runtime
>>>>                 + ?//Handle classData; // set to null. Will be
>>>>                 reinitialized at runtime
>>>>                 ? ?Handle mirror;
>>>>                 ? ?Handle comp_mirror;
>>>>                 ? ?allocate_mirror(k, /*is_scratch=*/true,
>>>>                 protection_domain, classData, mirror, comp_mirror,
>>>>                 CHECK);
>>>>
>>>>                 ? ?if (comp_mirror() != nullptr) {
>>>>                 diff --git
>>>>                 a/src/hotspot/share/classfile/javaClasses.hpp
>>>>                 b/src/hotspot/share/classfile/javaClasses.hpp
>>>>                 index bc49a0861a7..7ec2a2556dd 100644
>>>>                 --- a/src/hotspot/share/classfile/javaClasses.hpp
>>>>                 +++ b/src/hotspot/share/classfile/javaClasses.hpp
>>>>                 @@ -263,7 +263,7 @@ class java_lang_Class : AllStatic {
>>>>
>>>>                 ? ?// Archiving
>>>>                 ? ?static void serialize_offsets(SerializeClosure*
>>>>                 f) NOT_CDS_RETURN;
>>>>                 - ?static void create_scratch_mirror(Klass* k,
>>>>                 Handle protection_domain, TRAPS)
>>>>                 NOT_CDS_JAVA_HEAP_RETURN;
>>>>                 + ?static void create_scratch_mirror(Klass* k,
>>>>                 Handle protection_domain, Handle classData, TRAPS)
>>>>                 NOT_CDS_JAVA_HEAP_RETURN;
>>>>                 ? ?static bool restore_archived_mirror(Klass *k,
>>>>                 Handle class_loader, Handle module,
>>>>                 ? ? ? ?Handle protection_domain,
>>>>                 ? ? ? ?TRAPS) NOT_CDS_JAVA_HEAP_RETURN_(false);
>>>>
>>>>                 But this resulted in a different exception:
>>>>
>>>>                 Exception in thread "main"
>>>>                 java.lang.ExceptionInInitializerError
>>>>                 at com.redhat.leyden.Main.main(Main.java:7)
>>>>                 Caused by:
>>>>                 java.lang.invoke.WrongMethodTypeException: handle's
>>>>                 method type
>>>>                 (WildFlyElytronBaseProvider,Service)void but found
>>>>                 (WildFlyElytronBaseProvider,Service)void
>>>>                 at
>>>>                 java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>>>>                 at
>>>>                 java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>>>>                 at
>>>>                 java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
>>>>                 at
>>>>                 org.wildfly.security.WildFlyElytronBaseProvider$$Lambda/0x80000000c.accept(Unknown
>>>>                 Source)
>>>>                 at
>>>>                 org.wildfly.security.WildFlyElytronBaseProvider.putMakedPasswordImplementations(WildFlyElytronBaseProvider.java:112)
>>>>                 at
>>>>                 org.wildfly.security.WildFlyElytronBaseProvider.putPasswordImplementations(WildFlyElytronBaseProvider.java:107)
>>>>                 at
>>>>                 org.wildfly.security.password.WildFlyElytronPasswordProvider.<init>(WildFlyElytronPasswordProvider.java:43)
>>>>                 at
>>>>                 org.wildfly.security.password.WildFlyElytronPasswordProvider.<clinit>(WildFlyElytronPasswordProvider.java:36)
>>>>                 ... 1 more
>>>>
>>>>                 The exception message is strange because the
>>>>                 handle's method type and the expected type are both
>>>>                 symbolically the same.
>>>>                 I am debugging this exception at the moment.
>>>>                 Thanks,
>>>>                 - Ashutosh Mehra
>>>>
>>>>
>>>>                 On Wed, Sep 11, 2024 at 6:03?AM Andrew Dinn
>>>>                 <adinn at redhat.com> wrote:
>>>>
>>>>                     Oops, sorry, I debugged this a few days ago!
>>>>                     Correction to a few details:
>>>>
>>>>                     On 11/09/2024 10:39, Andrew Dinn wrote:
>>>>                     > A crash due to an NPE was observed in the
>>>>                     Infinispan (Data Grid) server
>>>>                     > app when deployed using the Leyden EA. The
>>>>                     crash still manifests with
>>>>                     > the latest premain code. The crash happens
>>>>                     below an application call
>>>>                     > which employs a method reference as argument
>>>>                     >
>>>>                     >
>>>>                     putMakedPasswordImplementations(this::putService,
>>>>                     this);
>>>>
>>>>                     The called method in turn calls consumer.accept
>>>>
>>>>                     ? ? ? ? ? ? ?consumer.accept(new Service(provider,
>>>>                     PASSWORD_FACTORY_TYPE, algorithm,
>>>>                     "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>>>                     emptyList,
>>>>                     emptyMap));
>>>>
>>>>                     which enters enters
>>>>                     MethodHandleNative::linkDynamicConstant()
>>>>
>>>>                     > Debugging shows that the call to
>>>>                     linkDynamicConstant() returns null.
>>>>                     >
>>>>                     > A simple reproducer for the problem is
>>>>                     available as a maven project on
>>>>                     > github:
>>>>                     >
>>>>                     >
>>>>                     https://github.com/tristantarrant/elytron-leyden
>>>>                     <https://urldefense.com/v3/__https://github.com/tristantarrant/elytron-leyden__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZaZr1akQ$>
>>>>                     >
>>>>                     > The ReadMe provides an explanation of how to
>>>>                     reproduce the problem. I
>>>>                     > did so and the debugged to find out some of
>>>>                     the details of what is
>>>>                     > happening (see below) but did not fully
>>>>                     clarify the problem. Help from
>>>>                     > someone more conversant with the ins and outs
>>>>                     of method handle
>>>>                     > bootstraps in premain would be welcome.
>>>>                     Details follow.
>>>>                     >
>>>>                     > regards,
>>>>                     >
>>>>                     >
>>>>                     > Andrew Dinn
>>>>                     > -----------
>>>>                     >
>>>>                     > I downloaded the git repo and attached the
>>>>                     Java sources using Maven command
>>>>                     >
>>>>                     >? ? $ mvn dependency:sources
>>>>                     >
>>>>                     > Having manifested the crash by following the
>>>>                     instructions in the README
>>>>                     > I reran the leyden JVM under gdb using the
>>>>                     following commands to enable
>>>>                     > Java debugging
>>>>                     >
>>>>                     > $ gdb ${LEYDEN_HOME}/bin/java
>>>>                     > (gdb) cd /path/to/mvn/project
>>>>                     > (gdb) run
>>>>                     >
>>>>                     -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
>>>>
>>>>                     > -classpath
>>>>                     >
>>>>                     /home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/2.5.1.
>>>>                     <https://urldefense.com/v3/__http://2.5.1.__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhauJ-RjcQ$>Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar
>>>>                     -XX:CacheDataStore=elytron.aot
>>>>                     com.redhat.leyden.Main
>>>>                     >
>>>>                     > The problem manifests at
>>>>                     WildflyElytronBaseProvider.java:112 in method
>>>>                     >
>>>>                     WildflyElytronBaseProvider::putMakedPasswordImplementations
>>>>
>>>>                     ? ? ?static void
>>>>                     putMakedPasswordImplementations(Consumer<Service>
>>>>                     consumer, Provider provider) {
>>>>                     ? ? ? ? ?for (String algorithm :
>>>>                     MASKED_ALGORITHMS) {
>>>>                     ? ? ? ? ? ? ?consumer.accept(new Service(provider,
>>>>                     PASSWORD_FACTORY_TYPE, algorithm,
>>>>                     "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>>>                     emptyList,
>>>>                     emptyMap)); <== NPE under this call
>>>>                     ? ? ? ? ?}
>>>>
>>>>
>>>>                     > The source code for this method can be found
>>>>                     in the following source jar
>>>>                     >
>>>>                     >
>>>>                     >
>>>>                     ${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar
>>>>                     >
>>>>                     > (where M2_REPO will normally be ~/.m2/repository)
>>>>                     >
>>>>                     > Stepping into accept eventually enters
>>>>                     MethodHandleNative::linkDynamicConstant
>>>>                     > which in turn enters into
>>>>                     ConstantBootstraps.makeConstant(). The caller
>>>>                     > Class at this point is a lambda class which
>>>>                     prints as
>>>>                     >
>>>>                     org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c
>>>>                     >
>>>>                     > Several steps further the code enters
>>>>                     BootstrapMethodInvoker::invoke
>>>>                     > (below the app method call but via 3 hidden
>>>>                     frames) with bootstrapMethod
>>>>                     > bound to a DirectMethodHandle. After several
>>>>                     more steps this enters
>>>>                     > DirectMethodHandle$Holder.invokeStatic which
>>>>                     in turn calls
>>>>                     > MethodHandles::classData(Lookup,String,Class).
>>>>                     >
>>>>                     > At this point caller is a MethodHandleLookup
>>>>                     for the lambda class
>>>>                     > Lambda/0x800000000c mentioned above. The
>>>>                     following call
>>>>                     >
>>>>                     >? ???????? Object classdata =
>>>>                     classData(caller.lookupClass());
>>>>                     >
>>>>                     > returns null to
>>>>                     DirectMethodHandle$Holder.invokeStatic which
>>>>                     pops the
>>>>                     > same result back out to
>>>>                     BootstrapMethodInvoker::invoke at line 90
>>>>                     >
>>>>                     >? ??????????????? if (type instanceof Class<?>
>>>>                     c) {
>>>>                     >? ??????????????????? result =
>>>>                     bootstrapMethod.invoke(caller, name, c);
>>>>                     > <== null
>>>>                     >
>>>>                     > This null result pops back out as the value
>>>>                     for the call to
>>>>                     > BootstrapMethodInvoker.invoke(),
>>>>                     ConstantBootstraps.makeConstant() and
>>>>                     > MethodHandleNative::linkDynamicConstant().
>>>>                     >
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240919/b7f017bc/attachment.htm>

From asmehra at redhat.com  Fri Sep 20 03:05:22 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Thu, 19 Sep 2024 23:05:22 -0400
Subject: premain: Crash in Infinispan server code caused by NPE under
 MethodHandleNative::linkDynamicConstant
In-Reply-To: <4dc70b95-f014-44f1-acfb-027c8e28e81d@oracle.com>
References: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
 <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>
 <CAKt0pySztvwsadtrqjai6XwakAWq_v_o8men4aopLo4X-0azyQ@mail.gmail.com>
 <CAKt0pyQ44E+npyUW35Zhxg+PfBgF2yuNgS61gj1GGj=aLGTJXw@mail.gmail.com>
 <CAKt0pyT48uPH6rUL7bEJ2rtWqNdNL34DWBJ2SDaHwYfVxURnQw@mail.gmail.com>
 <0d22d580-39a1-4105-a50e-8a74a555090d@oracle.com>
 <CAKt0pyRYBNtkLzVoAfDHWE=4e+9efZFb+xKYZv-d3LpDAU4qZg@mail.gmail.com>
 <da797fe2-137c-4fc7-a67c-3b595c0c63f2@oracle.com>
 <CAKt0pyRj8_mDiH58v10sqXNHA4iHja6-7D9N_S2VW9rhESPcTw@mail.gmail.com>
 <45e62b78-bbde-4ba5-8b20-77125d14b908@oracle.com>
 <4dc70b95-f014-44f1-acfb-027c8e28e81d@oracle.com>
Message-ID: <CAKt0pyQ8T+-yZQ1UJBewcc_DXTMRymNRSp3cz4xCZf54XUhw+g@mail.gmail.com>

>
> Upon further investigation, it seems a simple patch might fix the problem
> with classData.
>
> I tested with
> test/hotspot/jtreg/runtime/cds/appcds/LambdaWithUseImplMethodHandle.java by
> running jtreg with -javaoptions:-XX:+AOTClassLinking
> Without the patch, I'd get a NullPointerException. With the patch, the
> test passes.
>
> It looks like classData is not treated as a static field of the class, but
> rather an instance field in the mirror. So classData wasn't copied by the
> loop in HeapShared::copy_preinitialized_mirror().
>
> Ashutosh, could you try it this fixes the crash on your side?
>
> Thanks
>
> - Ioi
>
> diff --git a/src/hotspot/share/cds/heapShared.cpp
> b/src/hotspot/share/cds/heapShared.cpp
> index 0e70778f057..62cf142f67a 100644
> --- a/src/hotspot/share/cds/heapShared.cpp
> +++ b/src/hotspot/share/cds/heapShared.cpp
> @@ -634,6 +634,8 @@ void HeapShared::copy_preinitialized_mirror(Klass*
> orig_k, oop orig_mirror, oop
>      }
>    }
>
> +  java_lang_Class::set_class_data(m,
> java_lang_Class::class_data(orig_mirror));
> +
>    // Class::reflectData use SoftReference, which cannot be archived. Set
> it
>    // to null and it will be recreated at runtime.
>    java_lang_Class::set_reflection_data(m, nullptr);
>

Hi Ioi,

This patch effectively does the same thing as my initial patch for storing
classData in the scratch mirror object [1].

At this point I think it would be useful to do a quick recap of the issues
mentioned in this thread. There are 3 issues I have encountered so far.
I was initially thinking of a solution that would cover all these problems,
but looking at these again, I feel these are orthogonal to each other:

1. The missing classData in scratch mirrors which can be fixed by either of
the patches shared in this thread. They achieve the same goal and I don't
have any strong preference for any of them.

2. After fixing the classData, I ran into  WrongMethodTypeException issue
[2] which I fixed by exchanging the order of indy resolution with the call
to MethodType::createArchivedObjects [3].
This change makes sense because we want to make sure all the MethodType
objects that can be archived are in MethodType internTable before calling
MethodType::createArchivedObjects.
I am not sure why LambdaWithUseImplMethodHandle.java didn't throw the
WrongMethodTypeException, as the Infinispan code does.

3. After fixing the WrongMethodTypeException I hit NPE due to the class
initialization cycle between PrimitiveClassDescImpl and ConstantDescs [4]
in one of my own testcase.
We are looking for a solution to this problem. I am not sure if we can
break this cycle by refactoring the Java code.
Nevertheless, I think it is fair to assume that there is no Java code that
can initiate initialization of PrimitiveClassDescImpl before ConstantDescs,
otherwise we would have hit the NPE earlier.
So if ConstantDescs is always expected to be initialized before
PrimitiveClassDescImpl then I think the VM code should also maintain this
assumption.
Now this brings us back to the forceful initialization done by the VM
during the assembly phase based on the forced_preinit_classes list in
aotClassInitializer.cpp:

    // TODO:
    // This is needed since JDK-8338532. Without this, when
    // archived heap objects are used, the class init order is not
    // expected by the jdk/internal/constant bootstrap code and we
    // will get a null pointer exception.
    //
    // When bootstraping has intricated/fragile order, it's probably
    // better to archive all related classes in an initialized state
    // (i.e., take a snapshot). The existing approach in
    // heapShared::resolve_or_init_classes_for_subgraph_of() won't work.
    "jdk/internal/constant/PrimitiveClassDescImpl",
    "jdk/internal/constant/ReferenceClassDescImpl",
    "java/lang/constant/ConstantDescs",
    "sun/invoke/util/Wrapper",

I wonder why we need to explicitly add  PrimitiveClassDescImpl and
ReferenceClassDescImpl in this list.
Initialization of ConstantDescs would anyway trigger the initialization of
PrimitiveClassDescImpl and ReferenceClassDescImpl.
So if we only keep the entry for ConstantDescs and remove
PrimitiveClassDescImpl and ReferenceClassDescImpl from this list,
we can be sure that the forceful initialization by the VM would maintain
the same order of initialization as guided by the Java code,
and we will not hit the NPE when initializing PrimitiveClassDescImpl during
the assembly phase.
Does this make sense?


[1] https://mail.openjdk.org/pipermail/leyden-dev/2024-September/000994.html
[2] https://mail.openjdk.org/pipermail/leyden-dev/2024-September/000997.html
[3]
https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
[4] https://mail.openjdk.org/pipermail/leyden-dev/2024-September/001018.html

Thanks,
- Ashutosh Mehra


On Thu, Sep 19, 2024 at 8:51?PM <ioi.lam at oracle.com> wrote:

> Upon further investigation, it seems a simple patch might fix the problem
> with classData.
>
> I tested with
> test/hotspot/jtreg/runtime/cds/appcds/LambdaWithUseImplMethodHandle.java by
> running jtreg with -javaoptions:-XX:+AOTClassLinking
> Without the patch, I'd get a NullPointerException. With the patch, the
> test passes.
>
> It looks like classData is not treated as a static field of the class, but
> rather an instance field in the mirror. So classData wasn't copied by the
> loop in HeapShared::copy_preinitialized_mirror().
>
> Ashutosh, could you try it this fixes the crash on your side?
>
> Thanks
>
> - Ioi
>
> diff --git a/src/hotspot/share/cds/heapShared.cpp
> b/src/hotspot/share/cds/heapShared.cpp
> index 0e70778f057..62cf142f67a 100644
> --- a/src/hotspot/share/cds/heapShared.cpp
> +++ b/src/hotspot/share/cds/heapShared.cpp
> @@ -634,6 +634,8 @@ void HeapShared::copy_preinitialized_mirror(Klass*
> orig_k, oop orig_mirror, oop
>      }
>    }
>
> +  java_lang_Class::set_class_data(m,
> java_lang_Class::class_data(orig_mirror));
> +
>    // Class::reflectData use SoftReference, which cannot be archived. Set
> it
>    // to null and it will be recreated at runtime.
>    java_lang_Class::set_reflection_data(m, nullptr);
>
>
>
> On 9/19/24 12:51 PM, ioi.lam at oracle.com wrote:
>
>
> On 9/19/24 7:44 AM, Ashutosh Mehra wrote:
>
> As I am cleaning up the code for upstreaming to mainline, I am going add
>> an equivalent check in the C code to filter out these indy call sites, so
>> they won't be resolved at all during the assembly phase. Otherwise, I will
>> run into problems described in
>> https://bugs.openjdk.org/browse/JDK-8290417
>
>
> Thanks for the link to the bug. The scenario described in that bug is
> exactly the same as the Infinispan case.
> So if we filter out such cases during indy resolution then it should
> resolve the Infinispan issue as well.
>
> A basic question: why can't CDS handle the lambda proxy class generated in
> useImplMethodHandle mode?
>
> If I remember correctly, it has to do with the shape of dynamically
> generated bytecode:
>
>   public void accept(java.lang.Object);
>     Code:
>        0: ldc #28 // Dynamic #0:_:Ljava/lang/invoke/MethodHandle;
>        2: aload_0
>        3: getfield #15 // Field arg$1:LTester;
>        6: aload_1
>        7: checkcast #30 // class java/lang/String
>       10: invokevirtual #36 // Method
> java/lang/invoke/MethodHandle.invokeExact:(LTester;Ljava/lang/String;)V
>       13: return
>
> The result of the "ldc" was not symbolically encoded in the generated
> class (as the generated class has no permission to access that method). So
> the MethodHandle is stored as a binary object in the mirror of this
> generated class (with the java.lang.Class::classData field).
>
> Plain CDS doesn't archive class mirrors, so the classData will be lost.
>
> With JEP 483, we should be able to preserve the classData, so I am not
> sure why the useImplMethodHandle case is still failing. My plan is to
> filter these out for now, but I will get back to it later when I have more
> time.
>
> Thanks
>
> - Ioi
>
>
>
> Thanks,
> - Ashutosh Mehra
>
>
> On Thu, Sep 19, 2024 at 1:45?AM <ioi.lam at oracle.com> wrote:
>
>> Hi Ashutosh,
>>
>> I have some update:
>>
>> The original crash was caused by the "useImplMethodHandle" code in
>> InnerClassLambdaMetafactory.java:
>>
>>         // If the target class invokes a protected method inherited from a
>>         // superclass in a different package, or does 'invokespecial', the
>>         // lambda class has no access to the resolved method, or does
>>         // 'invokestatic' on a hidden class which cannot be resolved by
>> name.
>>         // Instead, we need to pass the live implementation method handle
>> to
>>         // the proxy class to invoke directly. (javac prefers to avoid
>> this
>>         // situation by generating bridges in the target class)
>>         useImplMethodHandle =
>> (Modifier.isProtected(implInfo.getModifiers()) &&
>>                                !VerifyAccess.isSamePackage(targetClass,
>> implInfo.getDeclaringClass())) ||
>>                                implKind ==
>> MethodHandleInfo.REF_invokeSpecial ||
>>                                implKind ==
>> MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>>
>> As I am cleaning up the code for upstreaming to mainline, I am going add
>> an equivalent check in the C code to filter out these indy call sites, so
>> they won't be resolved at all during the assembly phase. Otherwise, I will
>> run into problems described in
>> https://bugs.openjdk.org/browse/JDK-8290417
>>
>> Once I get the filtering code working, I will integrate it back to
>> premain.
>>
>> >I am wondering if we can workaround class circularity issues by
>> recording class initialization order
>> >during training run and use that to guide the initialization during
>> assembly phase.
>>
>> In the production run we take different paths than the training run
>>
>> (1) some classes are aot-initialized (especially the enums)
>> (2) some classes make special CDS calls
>>
>> so I am not sure if it's possible to get the same initialization order as
>> in the training run (or assembly phase).
>>
>> (more below)
>> On 9/18/24 9:10 AM, Ashutosh Mehra wrote:
>>
>> Hi Ioi,
>>
>> I was having a similar circularity issue (but in production time) and I
>>> just added enough classes to make the NPE go away.
>>>
>>
>> I am wondering if you have a test case that reproduces the NPE which
>> prompted you to add these classes:
>>
>>
>> https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp#L65-L78
>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp*L65-L78__;Iw!!ACWV5N9M2RV99hQ!NYvqLbb_Ib2kSdm2fcYVLGby-AiB2TG7KtC1HQHVKLiM-_kRb5mOt8krV5IZfReaYZ0MPadDfa08hQ$>
>>
>> I commented this code and ran the tests under premain but didn't hit the
>> NPE.
>>
>> I forgot what the problem was, but it happened for very simple cases.
>>
>> Thanks
>>
>> - Ioi
>>
>>
>> Thanks,
>> - Ashutosh Mehra
>>
>>
>> On Tue, Sep 17, 2024 at 1:11?AM <ioi.lam at oracle.com> wrote:
>>
>>> Hi Ashutosh,
>>>
>>> So this looks like a potential bug (or feature) in the core lib code.
>>> When CDS forcefully initializes a class in an unexpected (or untested)
>>> order, the "initialization soup" fails.
>>>
>>> Perhaps a work-around would be to make some harmless calls at the place
>>> where CDS was calling into MethodType.createArchivedObjects(). E.g., do
>>> something like this:
>>>
>>> +    if (CDSConfig::is_dumping_invokedynamic()) {
>>> +       // call into Java: jdk.internal.misc::warmupInvokeDynamic();
>>> +   }
>>>     // Rewrite and link classes
>>>     log_info(cds)("Rewriting and linking classes ...");
>>>
>>> Maybe you can add a new Lambda expressions, MethodHandle invocations,
>>> etc, that would hopefully cause PrimitiveClassDescImpl and friends to be
>>> initialized in their natural order.
>>>
>>> Or call class.forName("java.lang.constant.ConstantDescs") ??
>>>
>>> BTW, you can see my comments in
>>> AOTClassInitializer::is_forced_preinit_class():
>>>
>>>     // TODO:
>>>     // This is needed since JDK-8338532. Without this, when
>>>     // archived heap objects are used, the class init order is not
>>>     // expected by the jdk/internal/constant bootstrap code and we
>>>     // will get a null pointer exception.
>>>     //
>>>     // When bootstraping has intricated/fragile order, it's probably
>>>     // better to archive all related classes in an initialized state
>>>     // (i.e., take a snapshot). The existing approach in
>>>     // heapShared::resolve_or_init_classes_for_subgraph_of() won't work.
>>>     "jdk/internal/constant/PrimitiveClassDescImpl",
>>>     "jdk/internal/constant/ReferenceClassDescImpl",
>>>     "java/lang/constant/ConstantDescs",
>>>     "sun/invoke/util/Wrapper",
>>>
>>> I was having a similar circularity issue (but in production time) and I
>>> just added enough classes to make the NPE go away. For your test case, if
>>> you manage to fix in in the assembly run but run into NPE in production
>>> run, you might need to add more classes to this list. Yes, it's a hack :-(
>>>
>>>
>>> Thanks
>>>
>>> - Ioi
>>> On 9/13/24 7:05 PM, Ashutosh Mehra wrote:
>>>
>>> This is turning out to be a real example of class initialization soup!
>>> As mentioned during the meeting, I am getting NPE in the assembly phase
>>> when testing the patch [0] that I proposed in my earlier mail
>>> using a test case inspired by the Infinispan code.
>>> NPE occurs when running the class initializer for
>>> PrimitiveClassDescImpl
>>> Interestingly, PrimitiveClassDescImpl is "forcefully" initialized by
>>> MetaspaceShared::link_shared_classes().
>>>
>>> I couldn't get a stack trace so I relied on exception logs (using
>>> -Xlog:exceptions=trace) to find the cause which indicate following frames
>>> on the stack:
>>>
>>> [0]
>>> jdk/internal/constant/MethodTypeDescImpl::validateArgument(Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/ClassDesc; @
>>> bci 1
>>> [1]
>>> jdk/internal/constant/MethodTypeDescImpl::ofTrusted(Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljdk/internal/constant/MethodTypeDescImpl; @
>>> bci 27
>>> [2]
>>> java/lang/constant/ConstantDescs::ofConstantBootstrap(Ljava/lang/constant/ClassDesc;Ljava/lang/String;Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/DirectMethodHandleDesc; @
>>> bci 47
>>> [3] java/lang/constant/ConstantDescs::<clinit> @ bci 664
>>> [4]
>>> jdk/internal/constant/PrimitiveClassDescImpl::<init>(Ljava/lang/String;)V @
>>> bci 1
>>> [5]
>>> jdk/internal/constant/PrimitiveClassDescImpl::<clinit>(Ljava/lang/String;)V @
>>> bci 6
>>>
>>> Notice that invocation of PrimitiveClassDescImpl::<clinit> results in
>>> initialization of ConstantDescs class (see frame 3).
>>> ConstantDescs::<clinit> @ 664 corresponds to following java code:
>>>
>>>     public static final DirectMethodHandleDesc BSM_CLASS_DATA_AT
>>>             = ofConstantBootstrap(CD_MethodHandles, "classDataAt",
>>>             CD_Object, CD_int);
>>>
>>> The last parameter CD_int is initialized as:
>>>
>>>     public static final ClassDesc CD_int = PrimitiveClassDescImpl.CD_int;
>>>
>>> So, its value is obtained from PrimitiveClassDescImpl.CD_int which
>>> hasn't been initialized properly yet. As a result ConstantDescs::CD_int is
>>> assigned null which results in MethodTypeDescImpl::validateArgument
>>> throwing NPE later.
>>> There is a clear class initialization circularity involving
>>> PrimitiveClassDescImpl and ConstantDescs, and the result depends on
>>> which class gets initialized first.
>>>
>>> Without my patch this issue is not seen because PrimitiveClassDescImpl
>>> has already been initialized by the time
>>> MetaspaceShared::link_shared_classes() is called.
>>> Its initialization is triggered by the call to
>>> MethodType::createArchivedObjects().
>>> It also explains why my patch introduced this issue because it
>>> effectively moved the call to MethodType::createArchivedObjects() after
>>> MetaspaceShared::link_shared_classes().
>>>
>>> [0]
>>> https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>>
>>> Thanks,
>>> - Ashutosh Mehra
>>>
>>>
>>> On Wed, Sep 11, 2024 at 3:12?PM Ashutosh Mehra <asmehra at redhat.com>
>>> wrote:
>>>
>>>> Regarding the WrongMethodTypeException that I mentioned in my previous
>>>> email (see pt 3),
>>>> this exception happens when lambda proxy class attempts to invoke the
>>>> MethodHandle it obtained from the classData:
>>>>
>>>>   public void accept(java.lang.Object);
>>>>     descriptor: (Ljava/lang/Object;)V
>>>>     flags: (0x0001) ACC_PUBLIC
>>>>     Code:
>>>>       stack=3, locals=2, args_size=2
>>>>          0: ldc           #26                 // Dynamic
>>>> #0:_:Ljava/lang/invoke/MethodHandle;
>>>>          2: aload_0
>>>>          3: getfield      #13                 // Field
>>>> arg$1:Lorg/wildfly/security/WildFlyElytronBaseProvider;
>>>>          6: aload_1
>>>>          7: checkcast     #28                 // class
>>>> java/security/Provider$Service
>>>>         10: invokevirtual #34                 // Method
>>>> java/lang/invoke/MethodHandle.invokeExact:(Lorg/wildfly/security/WildFlyElytronBaseProvider;Ljava/security/Provider$Service;)V
>>>>         13: return
>>>>
>>>> The scenario is during the assembly phase as part of the indy
>>>> resolution the MethodHandle for which the exception is thrown gets created.
>>>> Normally MethodHandle's type gets added in MethodType::internTable but
>>>> by the time indy resolution happens, JVM has already taken
>>>> snapshot of the MethodType::internTable through an upcall to
>>>> MethodType::createArchivedObjects().
>>>> As a result the AOTCache ends up with the MethodType object which is
>>>> not in AOTHolder.archivedMethodTypes.
>>>>
>>>> During the production run, when the jvm invokes the MethodHandle, it
>>>> searches for the MethodType corresponding to the signature passed at the
>>>> callsite.
>>>> As expected, it fails to find it in the AOTHolder.archivedMethodTypes,
>>>> so it creates a new instance of the MethodType.
>>>> But Invokers.checkExactType() relies on the MethodHandle's type to be
>>>> the same object as the MethodType object passed as parameter.
>>>>
>>>>     static void checkExactType(MethodHandle mhM, MethodType expected) {
>>>>         MethodType targetType = mh.type();
>>>>         if (targetType != expected)
>>>>             throw newWrongMethodTypeException(targetType, expected);
>>>>     }
>>>>
>>>> Hence, it throws WrongMethodTypeException though the two MT objects
>>>> have the same signature.
>>>>
>>>> To handle this scenario, I changed the order of indy resolution and upcall
>>>> to MethodType::createArchivedObjects() as:
>>>>
>>>> diff --git a/src/hotspot/share/cds/metaspaceShared.cpp
>>>> b/src/hotspot/share/cds/metaspaceShared.cpp
>>>> index df4bcadefa3..457716cac5b 100644
>>>> --- a/src/hotspot/share/cds/metaspaceShared.cpp
>>>> +++ b/src/hotspot/share/cds/metaspaceShared.cpp
>>>> @@ -751,6 +751,20 @@ void MetaspaceShared::link_shared_classes(bool
>>>> jcmd_request, TRAPS) {
>>>>    if (CDSConfig::is_dumping_final_static_archive()) {
>>>>      FinalImageRecipes::apply_recipes(CHECK);
>>>>    }
>>>> +
>>>> +#if INCLUDE_CDS_JAVA_HEAP
>>>> +  if (CDSConfig::is_dumping_invokedynamic()) {
>>>> +    // This makes sure that the MethodType and MethodTypeForm tables
>>>> won't be updated
>>>> +    // concurrently when we are saving their contents into a side
>>>> table.
>>>> +    assert(CDSConfig::allow_only_single_java_thread(), "Required");
>>>> +
>>>> +    JavaValue result(T_VOID);
>>>> +    JavaCalls::call_static(&result, vmClasses::MethodType_klass(),
>>>> +                           vmSymbols::createArchivedObjects(),
>>>> +                           vmSymbols::void_method_signature(),
>>>> +                           CHECK);
>>>> +  }
>>>> +#endif
>>>>  }
>>>>
>>>> Note that indy resolution happens as part of FinalImageRecipes::apply_recipes(CHECK)
>>>> which is now invoked before the upcall to createArchivedObjects().
>>>> With this change I am able to run the application without any
>>>> exceptions.
>>>> My complete patch can be seen here:
>>>> https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>>> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>>> I will do more testing with this patch.
>>>>
>>>> @Ioi Lam <ioi.lam at oracle.com> do you have any feedback on this patch.
>>>>
>>>> Thanks,
>>>> - Ashutosh Mehra
>>>>
>>>>
>>>>
>>>> On Wed, Sep 11, 2024 at 10:14?AM Ashutosh Mehra <asmehra at redhat.com>
>>>> wrote:
>>>>
>>>>> Hi Andrew,
>>>>> Thanks for sharing the initial investigation.
>>>>> I have been looking into this and have a few of things to add to your
>>>>> analysis:
>>>>>
>>>>> 1.  As you mentioned the classData for the lambda
>>>>> class WildFlyElytronBaseProvider$$Lambda is null.
>>>>> The classData is stored in the mirror object of the InstanceKlass when
>>>>> the class is defined through JVM_LookupDefineClass.
>>>>> However, when we create the scratch mirror object (which get stored in
>>>>> the AOT cache) the classData is not populated.
>>>>> See
>>>>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp#L1128-L1131
>>>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp*L1128-L1131__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhbKjzG3gw$>
>>>>>
>>>>>   Handle classData; // set to null. Will be reinitialized at runtime
>>>>>   Handle mirror;
>>>>>   Handle comp_mirror;
>>>>>   allocate_mirror(k, /*is_scratch=*/true, protection_domain,
>>>>> classData, mirror, comp_mirror, CHECK);
>>>>>
>>>>> So this explains why the call to classData(caller.lookupClass())
>>>>> returned null.
>>>>>
>>>>> 2. In the mainline there is a check
>>>>> in InnerClassLambdaMetafactory.java for the particular code pattern used by
>>>>> the application.
>>>>> If this code pattern is found then the lambda proxy class is not
>>>>> included in the CDS archive.
>>>>> See
>>>>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L163-L170
>>>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L163-L170__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZl2S9tQg$>
>>>>> and
>>>>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L246
>>>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L246__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhYsI3Xx0g$>
>>>>>
>>>>>         // If the target class invokes a protected method inherited
>>>>> from a
>>>>>         // superclass in a different package, or does 'invokespecial',
>>>>> the
>>>>>         // lambda class has no access to the resolved method, or does
>>>>>         // 'invokestatic' on a hidden class which cannot be resolved
>>>>> by name.
>>>>>         // Instead, we need to pass the live implementation method
>>>>> handle to
>>>>>         // the proxy class to invoke directly. (javac prefers to avoid
>>>>> this
>>>>>         // situation by generating bridges in the target class)
>>>>>         useImplMethodHandle =
>>>>> (Modifier.isProtected(implInfo.getModifiers()) &&
>>>>>
>>>>>  !VerifyAccess.isSamePackage(targetClass, implInfo.getDeclaringClass())) ||
>>>>>                                implKind ==
>>>>> MethodHandleInfo.REF_invokeSpecial ||
>>>>>                                implKind ==
>>>>> MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>>>>>
>>>>> In premain lambda proxy classes get included in the AOT cache as a
>>>>> result of indy resolution and that mechanism doesn't have this kind of
>>>>> check.
>>>>>
>>>>> 3. For the null classData problem mentioned above, I tried to fix it
>>>>> by storing classData in the scratch mirror using the following patch:
>>>>>
>>>>> diff --git a/src/hotspot/share/classfile/javaClasses.cpp
>>>>> b/src/hotspot/share/classfile/javaClasses.cpp
>>>>> index bd8141adbcc..41766e98093 100644
>>>>> --- a/src/hotspot/share/classfile/javaClasses.cpp
>>>>> +++ b/src/hotspot/share/classfile/javaClasses.cpp
>>>>> @@ -1094,9 +1094,9 @@ void java_lang_Class::create_mirror(Klass* k,
>>>>> Handle class_loader,
>>>>>      }
>>>>>      if (CDSConfig::is_dumping_heap()) {
>>>>>        if (CDSConfig::is_dumping_protection_domains()) {
>>>>> -        create_scratch_mirror(k, protection_domain, CHECK);
>>>>> +        create_scratch_mirror(k, protection_domain, classData, CHECK);
>>>>>        } else {
>>>>> -        create_scratch_mirror(k, Handle() /* null
>>>>> protection_domain*/, CHECK);
>>>>> +        create_scratch_mirror(k, Handle() /* null
>>>>> protection_domain*/, classData, CHECK);
>>>>>        }
>>>>>      }
>>>>>    } else {
>>>>> @@ -1117,7 +1117,7 @@ void java_lang_Class::create_mirror(Klass* k,
>>>>> Handle class_loader,
>>>>>  // Note: we archive the "scratch mirror" instead of k->java_mirror(),
>>>>> because the
>>>>>  // latter may contain dumptime-specific information that cannot be
>>>>> archived
>>>>>  // (e.g., ClassLoaderData*, or static fields that are modified by
>>>>> Java code execution).
>>>>> -void java_lang_Class::create_scratch_mirror(Klass* k, Handle
>>>>> protection_domain, TRAPS) {
>>>>> +void java_lang_Class::create_scratch_mirror(Klass* k, Handle
>>>>> protection_domain, Handle classData, TRAPS) {
>>>>>    if (k->class_loader() != nullptr &&
>>>>>        k->class_loader() != SystemDictionary::java_platform_loader() &&
>>>>>        k->class_loader() != SystemDictionary::java_system_loader()) {
>>>>> @@ -1125,9 +1125,11 @@ void
>>>>> java_lang_Class::create_scratch_mirror(Klass* k, Handle protection_domain,
>>>>>      return;
>>>>>    }
>>>>>
>>>>> -  Handle classData; // set to null. Will be reinitialized at runtime
>>>>> +  //Handle classData; // set to null. Will be reinitialized at runtime
>>>>>    Handle mirror;
>>>>>    Handle comp_mirror;
>>>>>    allocate_mirror(k, /*is_scratch=*/true, protection_domain,
>>>>> classData, mirror, comp_mirror, CHECK);
>>>>>
>>>>>    if (comp_mirror() != nullptr) {
>>>>> diff --git a/src/hotspot/share/classfile/javaClasses.hpp
>>>>> b/src/hotspot/share/classfile/javaClasses.hpp
>>>>> index bc49a0861a7..7ec2a2556dd 100644
>>>>> --- a/src/hotspot/share/classfile/javaClasses.hpp
>>>>> +++ b/src/hotspot/share/classfile/javaClasses.hpp
>>>>> @@ -263,7 +263,7 @@ class java_lang_Class : AllStatic {
>>>>>
>>>>>    // Archiving
>>>>>    static void serialize_offsets(SerializeClosure* f) NOT_CDS_RETURN;
>>>>> -  static void create_scratch_mirror(Klass* k, Handle
>>>>> protection_domain, TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>>>>> +  static void create_scratch_mirror(Klass* k, Handle
>>>>> protection_domain, Handle classData, TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>>>>>    static bool restore_archived_mirror(Klass *k, Handle class_loader,
>>>>> Handle module,
>>>>>                                        Handle protection_domain,
>>>>>                                        TRAPS)
>>>>> NOT_CDS_JAVA_HEAP_RETURN_(false);
>>>>>
>>>>> But this resulted in a different exception:
>>>>>
>>>>> Exception in thread "main" java.lang.ExceptionInInitializerError
>>>>> at com.redhat.leyden.Main.main(Main.java:7)
>>>>> Caused by: java.lang.invoke.WrongMethodTypeException: handle's method
>>>>> type (WildFlyElytronBaseProvider,Service)void but found
>>>>> (WildFlyElytronBaseProvider,Service)void
>>>>> at
>>>>> java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>>>>> at
>>>>> java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>>>>> at
>>>>> java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
>>>>> at
>>>>> org.wildfly.security.WildFlyElytronBaseProvider$$Lambda/0x80000000c.accept(Unknown
>>>>> Source)
>>>>> at
>>>>> org.wildfly.security.WildFlyElytronBaseProvider.putMakedPasswordImplementations(WildFlyElytronBaseProvider.java:112)
>>>>> at
>>>>> org.wildfly.security.WildFlyElytronBaseProvider.putPasswordImplementations(WildFlyElytronBaseProvider.java:107)
>>>>> at
>>>>> org.wildfly.security.password.WildFlyElytronPasswordProvider.<init>(WildFlyElytronPasswordProvider.java:43)
>>>>> at
>>>>> org.wildfly.security.password.WildFlyElytronPasswordProvider.<clinit>(WildFlyElytronPasswordProvider.java:36)
>>>>> ... 1 more
>>>>>
>>>>> The exception message is strange because the handle's method type and
>>>>> the expected type are both symbolically the same.
>>>>> I am debugging this exception at the moment.
>>>>>
>>>>> Thanks,
>>>>> - Ashutosh Mehra
>>>>>
>>>>>
>>>>> On Wed, Sep 11, 2024 at 6:03?AM Andrew Dinn <adinn at redhat.com> wrote:
>>>>>
>>>>>> Oops, sorry, I debugged this a few days ago! Correction to a few
>>>>>> details:
>>>>>>
>>>>>> On 11/09/2024 10:39, Andrew Dinn wrote:
>>>>>> > A crash due to an NPE was observed in the Infinispan (Data Grid)
>>>>>> server
>>>>>> > app when deployed using the Leyden EA. The crash still manifests
>>>>>> with
>>>>>> > the latest premain code. The crash happens below an application
>>>>>> call
>>>>>> > which employs a method reference as argument
>>>>>> >
>>>>>> >          putMakedPasswordImplementations(this::putService, this);
>>>>>>
>>>>>> The called method in turn calls consumer.accept
>>>>>>
>>>>>>              consumer.accept(new Service(provider,
>>>>>> PASSWORD_FACTORY_TYPE, algorithm,
>>>>>> "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>>>>> emptyList,
>>>>>> emptyMap));
>>>>>>
>>>>>> which enters enters MethodHandleNative::linkDynamicConstant()
>>>>>>
>>>>>> > Debugging shows that the call to linkDynamicConstant() returns null.
>>>>>> >
>>>>>> > A simple reproducer for the problem is available as a maven project
>>>>>> on
>>>>>> > github:
>>>>>> >
>>>>>> >    https://github.com/tristantarrant/elytron-leyden
>>>>>> <https://urldefense.com/v3/__https://github.com/tristantarrant/elytron-leyden__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZaZr1akQ$>
>>>>>> >
>>>>>> > The ReadMe provides an explanation of how to reproduce the problem.
>>>>>> I
>>>>>> > did so and the debugged to find out some of the details of what is
>>>>>> > happening (see below) but did not fully clarify the problem. Help
>>>>>> from
>>>>>> > someone more conversant with the ins and outs of method handle
>>>>>> > bootstraps in premain would be welcome. Details follow.
>>>>>> >
>>>>>> > regards,
>>>>>> >
>>>>>> >
>>>>>> > Andrew Dinn
>>>>>> > -----------
>>>>>> >
>>>>>> > I downloaded the git repo and attached the Java sources using Maven
>>>>>> command
>>>>>> >
>>>>>> >    $ mvn dependency:sources
>>>>>> >
>>>>>> > Having manifested the crash by following the instructions in the
>>>>>> README
>>>>>> > I reran the leyden JVM under gdb using the following commands to
>>>>>> enable
>>>>>> > Java debugging
>>>>>> >
>>>>>> > $ gdb ${LEYDEN_HOME}/bin/java
>>>>>> > (gdb) cd /path/to/mvn/project
>>>>>> > (gdb) run
>>>>>> > -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
>>>>>> > -classpath
>>>>>> >
>>>>>> /home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/
>>>>>> 2.5.1.
>>>>>> <https://urldefense.com/v3/__http://2.5.1.__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhauJ-RjcQ$>Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar
>>>>>> -XX:CacheDataStore=elytron.aot com.redhat.leyden.Main
>>>>>> >
>>>>>> > The problem manifests at WildflyElytronBaseProvider.java:112 in
>>>>>> method
>>>>>> > WildflyElytronBaseProvider::putMakedPasswordImplementations
>>>>>>
>>>>>>      static void putMakedPasswordImplementations(Consumer<Service>
>>>>>> consumer, Provider provider) {
>>>>>>          for (String algorithm : MASKED_ALGORITHMS) {
>>>>>>              consumer.accept(new Service(provider,
>>>>>> PASSWORD_FACTORY_TYPE, algorithm,
>>>>>> "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>>>>> emptyList,
>>>>>> emptyMap)); <== NPE under this call
>>>>>>          }
>>>>>>
>>>>>>
>>>>>> > The source code for this method can be found in the following
>>>>>> source jar
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> ${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar
>>>>>> >
>>>>>> > (where M2_REPO will normally be ~/.m2/repository)
>>>>>> >
>>>>>> > Stepping into accept eventually enters
>>>>>> MethodHandleNative::linkDynamicConstant
>>>>>> > which in turn enters into ConstantBootstraps.makeConstant(). The
>>>>>> caller
>>>>>> > Class at this point is a lambda class which prints as
>>>>>> > org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c
>>>>>> >
>>>>>> > Several steps further the code enters
>>>>>> BootstrapMethodInvoker::invoke
>>>>>> > (below the app method call but via 3 hidden frames) with
>>>>>> bootstrapMethod
>>>>>> > bound to a DirectMethodHandle. After several more steps this enters
>>>>>> > DirectMethodHandle$Holder.invokeStatic which in turn calls
>>>>>> > MethodHandles::classData(Lookup,String,Class).
>>>>>> >
>>>>>> > At this point caller is a MethodHandleLookup for the lambda class
>>>>>> > Lambda/0x800000000c mentioned above. The following call
>>>>>> >
>>>>>> >           Object classdata = classData(caller.lookupClass());
>>>>>> >
>>>>>> > returns null to DirectMethodHandle$Holder.invokeStatic which pops
>>>>>> the
>>>>>> > same result back out to BootstrapMethodInvoker::invoke at line 90
>>>>>> >
>>>>>> >                  if (type instanceof Class<?> c) {
>>>>>> >                      result = bootstrapMethod.invoke(caller, name,
>>>>>> c);
>>>>>> > <== null
>>>>>> >
>>>>>> > This null result pops back out as the value for the call to
>>>>>> > BootstrapMethodInvoker.invoke(), ConstantBootstraps.makeConstant()
>>>>>> and
>>>>>> > MethodHandleNative::linkDynamicConstant().
>>>>>> >
>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240919/3760d7fb/attachment.htm>

From shade at openjdk.org  Fri Sep 20 07:37:03 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 20 Sep 2024 07:37:03 GMT
Subject: RFR: Workaround CacheDataStore use with source launcher [v2]
In-Reply-To: <WrCeEeFVm7bxm4NUhgdyT37ps3yEIqi81CM7UH86Ft4=.b0e35ac9-debe-4964-8ae0-c1b12cce5e34@github.com>
References: <YAyYOvD-NbB0hcUwUF9xCGmHkT0RDNLYXKdHSXRy0nY=.d338e229-985d-47ec-a6be-42ec8060d187@github.com>
 <WrCeEeFVm7bxm4NUhgdyT37ps3yEIqi81CM7UH86Ft4=.b0e35ac9-debe-4964-8ae0-c1b12cce5e34@github.com>
Message-ID: <_WDMNejFNZqvnC8A55KkjDk1kNPgZE0kTP9knMNSp94=.8c454b16-a49b-4299-a06e-0df60befdaca@github.com>

On Fri, 6 Sep 2024 08:59:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I was trying to test the simplest workload that involves javac, and that is source launcher. When I attempt to use source launcher with `-XX:CacheDataStore`, it fails with:
>> 
>> 
>> $ rm -f app.cds*; build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC HelloStream.java
>> [0.001s][warning][cds] optimized module handling/full module graph: disabled due to incompatible property: jdk.module.addmods=ALL-DEFAULT
>> Error occurred during initialization of VM
>> CacheDataStore cannot be created because AOTClassLinking is enabled but full module graph is disabled
>> 
>> 
>> Source launcher adds `--add-modules=ALL-DEFAULT`:
>> 
>> 
>> $ man java
>> ...
>>        In source-file mode, execution proceeds as follows:
>> 
>> ...
>>        ? The compiled classes are executed in  the  context  of  an  unnamed  module,  as  though  --add-mod?
>>          ules=ALL-DEFAULT  is  in  effect.  This is in addition to any other --add-module options that may be
>>          have been specified on the command line.
>> 
>> 
>> I think we can work that around specifically for Leyden, and also leave a TODO breadcrumb in the code that we need to figure this out on CDS side. This PR does that workaround. With it, source launcher works with simple examples:
>> 
>> 
>> $ build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC  HelloStream.java
>> Warning: CacheDataStore cannot be used with default source launcher environment, disabling --add-modules=ALL-DEFAULT
>> hello, world
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Indenting

No need for this anymore. We can just do javac tests directly.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/15#issuecomment-2363027170

From shade at openjdk.org  Fri Sep 20 07:37:03 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 20 Sep 2024 07:37:03 GMT
Subject: Withdrawn: Workaround CacheDataStore use with source launcher
In-Reply-To: <YAyYOvD-NbB0hcUwUF9xCGmHkT0RDNLYXKdHSXRy0nY=.d338e229-985d-47ec-a6be-42ec8060d187@github.com>
References: <YAyYOvD-NbB0hcUwUF9xCGmHkT0RDNLYXKdHSXRy0nY=.d338e229-985d-47ec-a6be-42ec8060d187@github.com>
Message-ID: <MZefJhRq5houWzpspUG_HWCwKkldkQarbeOt44MATT0=.c0070578-9437-4f2a-bf88-f6377bb8e002@github.com>

On Fri, 6 Sep 2024 08:51:57 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I was trying to test the simplest workload that involves javac, and that is source launcher. When I attempt to use source launcher with `-XX:CacheDataStore`, it fails with:
> 
> 
> $ rm -f app.cds*; build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC HelloStream.java
> [0.001s][warning][cds] optimized module handling/full module graph: disabled due to incompatible property: jdk.module.addmods=ALL-DEFAULT
> Error occurred during initialization of VM
> CacheDataStore cannot be created because AOTClassLinking is enabled but full module graph is disabled
> 
> 
> Source launcher adds `--add-modules=ALL-DEFAULT`:
> 
> 
> $ man java
> ...
>        In source-file mode, execution proceeds as follows:
> 
> ...
>        ? The compiled classes are executed in  the  context  of  an  unnamed  module,  as  though  --add-mod?
>          ules=ALL-DEFAULT  is  in  effect.  This is in addition to any other --add-module options that may be
>          have been specified on the command line.
> 
> 
> I think we can work that around specifically for Leyden, and also leave a TODO breadcrumb in the code that we need to figure this out on CDS side. This PR does that workaround. With it, source launcher works with simple examples:
> 
> 
> $ build/linux-x86_64-server-release/images/jdk/bin/java -XX:CacheDataStore=app.cds -Xmx256m -Xms256m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC  HelloStream.java
> Warning: CacheDataStore cannot be used with default source launcher environment, disabling --add-modules=ALL-DEFAULT
> hello, world

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/leyden/pull/15

From dhanalla at openjdk.org  Fri Sep 20 23:34:18 2024
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Fri, 20 Sep 2024 23:34:18 GMT
Subject: RFR: 8340559: [premain] java process crash with -XX:+PrintTrainingInfo
Message-ID: <E-Ex5cmTgkMOH2HAxcjhIgK0CL04tX-pyz_hswQ-sC8=.d8990b87-2d01-4967-bb4d-428a6043004f@github.com>

Java process crashes during training run with -XX:+PrintTrainingInfo as some of the _holder (i.e InstanceKlass and Method) objects are null in KlassTrainingData and MethodTrainingData.

repro command:
java -XX:+PrintTrainingInfo -XX:CacheDataStore=JavacBenchApp.cds -cp JavacBenchApp.jar JavacBenchApp 50

-------------

Commit messages:
 - [premain] java process crash with -XX:+PrintTrainingInfo

Changes: https://git.openjdk.org/leyden/pull/23/files
  Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=23&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340559
  Stats: 8 lines in 1 file changed: 3 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/leyden/pull/23.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/23/head:pull/23

PR: https://git.openjdk.org/leyden/pull/23

From iveresov at openjdk.org  Mon Sep 23 18:23:52 2024
From: iveresov at openjdk.org (Igor Veresov)
Date: Mon, 23 Sep 2024 18:23:52 GMT
Subject: RFR: 8340559: [premain] java process crash with
 -XX:+PrintTrainingInfo
In-Reply-To: <E-Ex5cmTgkMOH2HAxcjhIgK0CL04tX-pyz_hswQ-sC8=.d8990b87-2d01-4967-bb4d-428a6043004f@github.com>
References: <E-Ex5cmTgkMOH2HAxcjhIgK0CL04tX-pyz_hswQ-sC8=.d8990b87-2d01-4967-bb4d-428a6043004f@github.com>
Message-ID: <mYgyCTmQkzeYQNhUxxZrUQF76wYf15N1dau4rDej3CQ=.72435ee5-2a37-4493-8946-8da997f39015@github.com>

On Fri, 20 Sep 2024 23:29:09 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

> Java process crashes during training run with -XX:+PrintTrainingInfo as some of the _holder (i.e InstanceKlass and Method) objects are null in KlassTrainingData and MethodTrainingData.
> 
> repro command:
> java -XX:+PrintTrainingInfo -XX:CacheDataStore=JavacBenchApp.cds -cp JavacBenchApp.jar JavacBenchApp 50

Marked as reviewed by iveresov (Committer).

-------------

PR Review: https://git.openjdk.org/leyden/pull/23#pullrequestreview-2323010828

From duke at openjdk.org  Mon Sep 23 19:36:45 2024
From: duke at openjdk.org (duke)
Date: Mon, 23 Sep 2024 19:36:45 GMT
Subject: RFR: 8340559: [premain] java process crash with
 -XX:+PrintTrainingInfo
In-Reply-To: <E-Ex5cmTgkMOH2HAxcjhIgK0CL04tX-pyz_hswQ-sC8=.d8990b87-2d01-4967-bb4d-428a6043004f@github.com>
References: <E-Ex5cmTgkMOH2HAxcjhIgK0CL04tX-pyz_hswQ-sC8=.d8990b87-2d01-4967-bb4d-428a6043004f@github.com>
Message-ID: <cnovJybwgOIXja3crRPd6xy2LowMF_ukswjgB49HvV4=.43d7c26b-10b8-4df9-a2f1-6f8774fa9922@github.com>

On Fri, 20 Sep 2024 23:29:09 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

> Java process crashes during training run with -XX:+PrintTrainingInfo as some of the _holder (i.e InstanceKlass and Method) objects are null in KlassTrainingData and MethodTrainingData.
> 
> repro command:
> java -XX:+PrintTrainingInfo -XX:CacheDataStore=JavacBenchApp.cds -cp JavacBenchApp.jar JavacBenchApp 50

@dhanalla 
Your change (at version f3b4f0029ce2d5d6f20e90a5eca4def248816f97) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/23#issuecomment-2369195861

From iveresov at openjdk.org  Mon Sep 23 19:46:21 2024
From: iveresov at openjdk.org (Igor Veresov)
Date: Mon, 23 Sep 2024 19:46:21 GMT
Subject: git: openjdk/leyden: premain: 8340559: [premain] java process crash
 with -XX:+PrintTrainingInfo
Message-ID: <e2a63842-8108-47c0-837b-3777834ebedc@openjdk.org>

Changeset: 6c83df44
Branch: premain
Author:    Dhamoder Nalla <dhanalla at openjdk.org>
Committer: Igor Veresov <iveresov at openjdk.org>
Date:      2024-09-23 19:45:31 +0000
URL:       https://git.openjdk.org/leyden/commit/6c83df445fc66c85d8bc265f4e09407fbc565379

8340559: [premain] java process crash with -XX:+PrintTrainingInfo

Reviewed-by: iveresov

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


From dhanalla at openjdk.org  Mon Sep 23 19:48:59 2024
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Mon, 23 Sep 2024 19:48:59 GMT
Subject: Integrated: 8340559: [premain] java process crash with
 -XX:+PrintTrainingInfo
In-Reply-To: <E-Ex5cmTgkMOH2HAxcjhIgK0CL04tX-pyz_hswQ-sC8=.d8990b87-2d01-4967-bb4d-428a6043004f@github.com>
References: <E-Ex5cmTgkMOH2HAxcjhIgK0CL04tX-pyz_hswQ-sC8=.d8990b87-2d01-4967-bb4d-428a6043004f@github.com>
Message-ID: <tYs0TyoJN-j0rWAPVR24oRCUccLjsFWaX1ftR40VZ8k=.4b9a5c69-d57b-46da-8f0b-2aa30bae53f1@github.com>

On Fri, 20 Sep 2024 23:29:09 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

> Java process crashes during training run with -XX:+PrintTrainingInfo as some of the _holder (i.e InstanceKlass and Method) objects are null in KlassTrainingData and MethodTrainingData.
> 
> repro command:
> java -XX:+PrintTrainingInfo -XX:CacheDataStore=JavacBenchApp.cds -cp JavacBenchApp.jar JavacBenchApp 50

This pull request has now been integrated.

Changeset: 6c83df44
Author:    Dhamoder Nalla <dhanalla at openjdk.org>
Committer: Igor Veresov <iveresov at openjdk.org>
URL:       https://git.openjdk.org/leyden/commit/6c83df445fc66c85d8bc265f4e09407fbc565379
Stats:     8 lines in 1 file changed: 3 ins; 1 del; 4 mod

8340559: [premain] java process crash with -XX:+PrintTrainingInfo

Reviewed-by: iveresov

-------------

PR: https://git.openjdk.org/leyden/pull/23

From ioi.lam at oracle.com  Tue Sep 24 03:24:05 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Mon, 23 Sep 2024 20:24:05 -0700
Subject: premain: Crash in Infinispan server code caused by NPE under
 MethodHandleNative::linkDynamicConstant
In-Reply-To: <CAKt0pyQ8T+-yZQ1UJBewcc_DXTMRymNRSp3cz4xCZf54XUhw+g@mail.gmail.com>
References: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
 <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>
 <CAKt0pySztvwsadtrqjai6XwakAWq_v_o8men4aopLo4X-0azyQ@mail.gmail.com>
 <CAKt0pyQ44E+npyUW35Zhxg+PfBgF2yuNgS61gj1GGj=aLGTJXw@mail.gmail.com>
 <CAKt0pyT48uPH6rUL7bEJ2rtWqNdNL34DWBJ2SDaHwYfVxURnQw@mail.gmail.com>
 <0d22d580-39a1-4105-a50e-8a74a555090d@oracle.com>
 <CAKt0pyRYBNtkLzVoAfDHWE=4e+9efZFb+xKYZv-d3LpDAU4qZg@mail.gmail.com>
 <da797fe2-137c-4fc7-a67c-3b595c0c63f2@oracle.com>
 <CAKt0pyRj8_mDiH58v10sqXNHA4iHja6-7D9N_S2VW9rhESPcTw@mail.gmail.com>
 <45e62b78-bbde-4ba5-8b20-77125d14b908@oracle.com>
 <4dc70b95-f014-44f1-acfb-027c8e28e81d@oracle.com>
 <CAKt0pyQ8T+-yZQ1UJBewcc_DXTMRymNRSp3cz4xCZf54XUhw+g@mail.gmail.com>
Message-ID: <9ec705a7-4fa5-40f8-8685-b49c54ab4418@oracle.com>

Hi Ashutosh,

Thank you again for the summary of the issues.

I looked at the call paths again and I think two calls need to be moved

    (1) MethodType::createArchivedObjects() needs to be called after we
    have executed all other Java code. So I put it before the
    StringTable::allocate_shared_strings_array() call.

    (2) SystemDictionary::get_all_method_handle_intrinsics() needs to be
    done inside the safepoint, so it can be sure to find all the method
    handle intrinsic methods (which can be generated as the side effect
    of Java code execution).

    I also added the archiving of the classData field.

See my temporary change at 
https://github.com/iklam/jdk/commit/eafaa9731ae89b93f3e20702fc4d5a12cb070149

With this change, I am able to successfully run the test in 
https://github.com/tristantarrant/elytron-leyden . I also modified the 
LambdaWithUseImplMethodHandle.java test to add a similar test scenario.

I agree with you that the code in 
AOTClassInitializer::is_forced_preinit_class() is too ad-hoc, and might 
change the order of class initialization. In the upstream PR, I have 
changed the code to only assert that the listed of classes has been 
initialized:

https://github.com/iklam/jdk/blob/5cc31ed60cc9597d63b86f20b95c964d4d1a6b84/src/hotspot/share/cds/aotClassInitializer.cpp#L66-L84

I will try to merge this version of the code back to the Leyden repo.

I think by doing this, we can avoid direct manipulation of the 
class-init order of the core-library classes. Instead, we just make sure 
that we execute enough "normal" code during the assembly phase to ensure 
that these classes are initialized in their normal order.

What do you think?

Thanks

- Ioi


On 9/19/24 8:05 PM, Ashutosh Mehra wrote:
>
>     Upon further investigation, it seems a simple patch might fix the
>     problem with classData.
>
>     I tested with
>     test/hotspot/jtreg/runtime/cds/appcds/LambdaWithUseImplMethodHandle.java
>     by running jtreg with -javaoptions:-XX:+AOTClassLinking
>     Without the patch, I'd get a NullPointerException. With the patch,
>     the test passes.
>
>     It looks like classData is not treated as a static field of the
>     class, but rather an instance field in the mirror. So classData
>     wasn't copied by the loop in HeapShared::copy_preinitialized_mirror().
>
>     Ashutosh, could you try it this fixes the crash on your side?
>
>     Thanks
>
>     - Ioi
>
>     diff --git a/src/hotspot/share/cds/heapShared.cpp
>     b/src/hotspot/share/cds/heapShared.cpp
>     index 0e70778f057..62cf142f67a 100644
>     --- a/src/hotspot/share/cds/heapShared.cpp
>     +++ b/src/hotspot/share/cds/heapShared.cpp
>     @@ -634,6 +634,8 @@ void
>     HeapShared::copy_preinitialized_mirror(Klass* orig_k, oop
>     orig_mirror, oop
>     ???? }
>     ?? }
>
>     +? java_lang_Class::set_class_data(m,
>     java_lang_Class::class_data(orig_mirror));
>     +
>     ?? // Class::reflectData use SoftReference, which cannot be
>     archived. Set it
>     ?? // to null and it will be recreated at runtime.
>     ?? java_lang_Class::set_reflection_data(m, nullptr);
>
>
> Hi Ioi,
>
> This patch effectively does the same thing as my initial patch for 
> storing classData in the scratch mirror object [1].
>
> At this point I think it would be useful to do a quick recap of the 
> issues mentioned in this thread. There are 3 issues I have encountered 
> so far.
> I was initially thinking of a solution that would cover all these 
> problems, but looking at these again, I feel these are orthogonal to 
> each other:
>
> 1. The missing classData in scratch mirrors which can be fixed by 
> either of the patches shared in this thread. They achieve the same 
> goal and I don't have any strong preference for any of them.
>
> 2. After fixing the classData, I ran into WrongMethodTypeException 
> issue [2] which I fixed by exchanging the order of indy resolution 
> with the call to MethodType::createArchivedObjects [3].
> This change makes sense because we want to make sure all the 
> MethodType objects that can be archived are in MethodType?internTable 
> before calling MethodType::createArchivedObjects.
> I am not sure why LambdaWithUseImplMethodHandle.java didn't throw the 
> WrongMethodTypeException, as the Infinispan code does.
>
> 3. After fixing the WrongMethodTypeException I hit NPE due to the 
> class initialization cycle between PrimitiveClassDescImpl?and 
> ConstantDescs [4] in one of my own testcase.
> We are looking for a solution to this problem. I am not sure if we can 
> break this cycle by?refactoring the?Java code.
> Nevertheless, I think it is fair to assume that there is no Java code 
> that can initiate initialization of PrimitiveClassDescImpl 
> beforeConstantDescs, otherwise we would have hit the NPE earlier.
> So if ConstantDescsis always expected to be initialized before 
> PrimitiveClassDescImpl?then I think the VM code should also maintain 
> this assumption.
> Now this brings us back to the forceful initialization done by the VM 
> during the assembly phase based on the forced_preinit_classes list in 
> aotClassInitializer.cpp:
>
> ? ? // TODO:
> ? ? // This is needed since JDK-8338532. Without this, when
> ? ? // archived heap objects are used, the class init order is not
> ? ? // expected by the jdk/internal/constant bootstrap code and we
> ? ? // will get a null pointer exception.
> ? ? //
> ? ? // When bootstraping has intricated/fragile order, it's probably
> ? ? // better to archive all related classes in an initialized state
> ? ? // (i.e., take a snapshot). The existing approach in
> ? ? // heapShared::resolve_or_init_classes_for_subgraph_of() won't work.
> ? ? "jdk/internal/constant/PrimitiveClassDescImpl",
> ? ? "jdk/internal/constant/ReferenceClassDescImpl",
> ? ? "java/lang/constant/ConstantDescs",
> ? ? "sun/invoke/util/Wrapper",
>
> I wonder why we need to explicitly add PrimitiveClassDescImpl?and 
> ReferenceClassDescImpl?in this list.
> Initialization of ConstantDescs?would anyway trigger the 
> initialization of PrimitiveClassDescImpl?and ReferenceClassDescImpl.
> So if we only keep the entry for ConstantDescs?and remove 
> PrimitiveClassDescImpl?and ReferenceClassDescImpl?from this list,
> we can be sure that the forceful initialization by the VM would 
> maintain the same order of initialization as guided by the Java code,
> and we will not hit the NPE when initializing PrimitiveClassDescImpl 
> during the assembly phase.
> Does this make sense?
>
>
> [1] 
> https://mail.openjdk.org/pipermail/leyden-dev/2024-September/000994.html
> [2] 
> https://mail.openjdk.org/pipermail/leyden-dev/2024-September/000997.html
> [3] 
> https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e 
> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!KvYLs_vG0a4GO3ltinXQkxBG1kMhCAvmmM6MwODoKzOhhVjzNL80S_0mBzYvYyhYPQnGmXhAXSw78Q$>
> [4] 
> https://mail.openjdk.org/pipermail/leyden-dev/2024-September/001018.html
>
> Thanks,
> - Ashutosh Mehra
>
>
> On Thu, Sep 19, 2024 at 8:51?PM <ioi.lam at oracle.com> wrote:
>
>     Upon further investigation, it seems a simple patch might fix the
>     problem with classData.
>
>     I tested with
>     test/hotspot/jtreg/runtime/cds/appcds/LambdaWithUseImplMethodHandle.java
>     by running jtreg with -javaoptions:-XX:+AOTClassLinking
>     Without the patch, I'd get a NullPointerException. With the patch,
>     the test passes.
>
>     It looks like classData is not treated as a static field of the
>     class, but rather an instance field in the mirror. So classData
>     wasn't copied by the loop in HeapShared::copy_preinitialized_mirror().
>
>     Ashutosh, could you try it this fixes the crash on your side?
>
>     Thanks
>
>     - Ioi
>
>     diff --git a/src/hotspot/share/cds/heapShared.cpp
>     b/src/hotspot/share/cds/heapShared.cpp
>     index 0e70778f057..62cf142f67a 100644
>     --- a/src/hotspot/share/cds/heapShared.cpp
>     +++ b/src/hotspot/share/cds/heapShared.cpp
>     @@ -634,6 +634,8 @@ void
>     HeapShared::copy_preinitialized_mirror(Klass* orig_k, oop
>     orig_mirror, oop
>     ???? }
>     ?? }
>
>     +? java_lang_Class::set_class_data(m,
>     java_lang_Class::class_data(orig_mirror));
>     +
>     ?? // Class::reflectData use SoftReference, which cannot be
>     archived. Set it
>     ?? // to null and it will be recreated at runtime.
>     ?? java_lang_Class::set_reflection_data(m, nullptr);
>
>
>
>     On 9/19/24 12:51 PM, ioi.lam at oracle.com wrote:
>>
>>
>>     On 9/19/24 7:44 AM, Ashutosh Mehra wrote:
>>>
>>>         As I am cleaning up the code for upstreaming to mainline, I
>>>         am going add an equivalent check in the C code to filter out
>>>         these indy call sites, so they won't be resolved at all
>>>         during the assembly phase. Otherwise, I will run into
>>>         problems described in
>>>         https://bugs.openjdk.org/browse/JDK-8290417
>>>
>>>
>>>     Thanks for the link to the bug. The scenario described in that
>>>     bug is exactly the same as the Infinispan case.
>>>     So if we filter out such cases during indy resolution then it
>>>     should resolve the Infinispan issue as well.
>>>
>>>     A basic question: why?can't CDS handle the lambda proxy class
>>>     generated in useImplMethodHandle?mode?
>>>
>>     If I remember correctly, it has to do with the shape of
>>     dynamically generated bytecode:
>>
>>     ? public void accept(java.lang.Object);
>>     ??? Code:
>>     ?????? 0: ldc #28 // Dynamic #0:_:Ljava/lang/invoke/MethodHandle;
>>     ?????? 2: aload_0
>>     ?????? 3: getfield #15 // Field arg$1:LTester;
>>     ?????? 6: aload_1
>>     ?????? 7: checkcast #30 // class java/lang/String
>>     ????? 10: invokevirtual #36 // Method
>>     java/lang/invoke/MethodHandle.invokeExact:(LTester;Ljava/lang/String;)V
>>     ????? 13: return
>>
>>     The result of the "ldc" was not symbolically encoded in the
>>     generated class (as the generated class has no permission to
>>     access that method). So the MethodHandle is stored as a binary
>>     object in the mirror of this generated class (with the
>>     java.lang.Class::classData field).
>>
>>     Plain CDS doesn't archive class mirrors, so the classData will be
>>     lost.
>>
>>     With JEP 483, we should be able to preserve the classData, so I
>>     am not sure why the useImplMethodHandle case is still failing. My
>>     plan is to filter these out for now, but I will get back to it
>>     later when I have more time.
>>
>>     Thanks
>>
>>     - Ioi
>>
>>
>>
>>
>>>     Thanks,
>>>     - Ashutosh Mehra
>>>
>>>
>>>     On Thu, Sep 19, 2024 at 1:45?AM <ioi.lam at oracle.com> wrote:
>>>
>>>         Hi Ashutosh,
>>>
>>>         I have some update:
>>>
>>>         The original crash was caused by the "useImplMethodHandle"
>>>         code in InnerClassLambdaMetafactory.java:
>>>
>>>         ??????? // If the target class invokes a protected method
>>>         inherited from a
>>>         ??????? // superclass in a different package, or does
>>>         'invokespecial', the
>>>         ??????? // lambda class has no access to the resolved
>>>         method, or does
>>>         ??????? // 'invokestatic' on a hidden class which cannot be
>>>         resolved by name.
>>>         ??????? // Instead, we need to pass the live implementation
>>>         method handle to
>>>         ??????? // the proxy class to invoke directly. (javac
>>>         prefers to avoid this
>>>         ??????? // situation by generating bridges in the target class)
>>>         ??????? useImplMethodHandle =
>>>         (Modifier.isProtected(implInfo.getModifiers()) &&
>>>         !VerifyAccess.isSamePackage(targetClass,
>>>         implInfo.getDeclaringClass())) ||
>>>         ?????????????????????????????? implKind ==
>>>         MethodHandleInfo.REF_invokeSpecial ||
>>>         ?????????????????????????????? implKind ==
>>>         MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>>>
>>>         As I am cleaning up the code for upstreaming to mainline, I
>>>         am going add an equivalent check in the C code to filter out
>>>         these indy call sites, so they won't be resolved at all
>>>         during the assembly phase. Otherwise, I will run into
>>>         problems described in
>>>         https://bugs.openjdk.org/browse/JDK-8290417
>>>
>>>         Once I get the filtering code working, I will integrate it
>>>         back to premain.
>>>
>>>         >I am wondering if we can workaround class circularity
>>>         issues by recording class initialization order
>>>         >during training run and use that to guide the
>>>         initialization during assembly phase.
>>>
>>>         In the production run we take different paths than the
>>>         training run
>>>
>>>         (1) some classes are aot-initialized (especially the enums)
>>>         (2) some classes make special CDS calls
>>>
>>>         so I am not sure if it's possible to get the same
>>>         initialization order as in the training run (or assembly phase).
>>>
>>>         (more below)
>>>
>>>         On 9/18/24 9:10 AM, Ashutosh Mehra wrote:
>>>>         Hi Ioi,
>>>>
>>>>             I was having a similar circularity issue (but in
>>>>             production time) and I just added enough classes to
>>>>             make the NPE go away.
>>>>
>>>>         I am wondering if you have a test case that reproduces the
>>>>         NPE which prompted you to add these classes:
>>>>
>>>>         https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp#L65-L78
>>>>         <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp*L65-L78__;Iw!!ACWV5N9M2RV99hQ!NYvqLbb_Ib2kSdm2fcYVLGby-AiB2TG7KtC1HQHVKLiM-_kRb5mOt8krV5IZfReaYZ0MPadDfa08hQ$>
>>>>
>>>>         I commented this code and ran the tests under premain but
>>>>         didn't hit?the NPE.
>>>>
>>>         I forgot what the problem was, but it happened for very
>>>         simple cases.
>>>
>>>         Thanks
>>>
>>>         - Ioi
>>>
>>>
>>>>         Thanks,
>>>>         - Ashutosh Mehra
>>>>
>>>>
>>>>         On Tue, Sep 17, 2024 at 1:11?AM <ioi.lam at oracle.com> wrote:
>>>>
>>>>             Hi Ashutosh,
>>>>
>>>>             So this looks like a potential bug (or feature) in the
>>>>             core lib code. When CDS forcefully initializes a class
>>>>             in an unexpected (or untested) order, the
>>>>             "initialization soup" fails.
>>>>
>>>>             Perhaps a work-around would be to make some harmless
>>>>             calls at the place where CDS was calling into
>>>>             MethodType.createArchivedObjects(). E.g., do something
>>>>             like this:
>>>>
>>>>             +??? if (CDSConfig::is_dumping_invokedynamic()) {
>>>>             +?????? // call into Java:
>>>>             jdk.internal.misc::warmupInvokeDynamic();
>>>>             +?? }
>>>>             ??? // Rewrite and link classes
>>>>             ??? log_info(cds)("Rewriting and linking classes ...");
>>>>
>>>>             Maybe you can add a new Lambda expressions,
>>>>             MethodHandle invocations, etc, that would hopefully
>>>>             cause PrimitiveClassDescImpl and friends to be
>>>>             initialized in their natural order.
>>>>
>>>>             Or call
>>>>             class.forName("java.lang.constant.ConstantDescs") ??
>>>>
>>>>             BTW, you can see my comments in
>>>>             AOTClassInitializer::is_forced_preinit_class():
>>>>
>>>>             ??? // TODO:
>>>>             ??? // This is needed since JDK-8338532. Without this, when
>>>>             ??? // archived heap objects are used, the class init
>>>>             order is not
>>>>             ??? // expected by the jdk/internal/constant bootstrap
>>>>             code and we
>>>>             ??? // will get a null pointer exception.
>>>>             ??? //
>>>>             ??? // When bootstraping has intricated/fragile order,
>>>>             it's probably
>>>>             ??? // better to archive all related classes in an
>>>>             initialized state
>>>>             ??? // (i.e., take a snapshot). The existing approach in
>>>>             ??? //
>>>>             heapShared::resolve_or_init_classes_for_subgraph_of()
>>>>             won't work.
>>>>             "jdk/internal/constant/PrimitiveClassDescImpl",
>>>>             "jdk/internal/constant/ReferenceClassDescImpl",
>>>>             ??? "java/lang/constant/ConstantDescs",
>>>>             ??? "sun/invoke/util/Wrapper",
>>>>
>>>>             I was having a similar circularity issue (but in
>>>>             production time) and I just added enough classes to
>>>>             make the NPE go away. For your test case, if you manage
>>>>             to fix in in the assembly run but run into NPE in
>>>>             production run, you might need to add more classes to
>>>>             this list. Yes, it's a hack :-(
>>>>
>>>>
>>>>             Thanks
>>>>
>>>>             - Ioi
>>>>
>>>>             On 9/13/24 7:05 PM, Ashutosh Mehra wrote:
>>>>>             This is turning out to be a real example of class
>>>>>             initialization soup!
>>>>>             As mentioned during the meeting, I am getting NPE in
>>>>>             the assembly phase when testing the patch [0] that I
>>>>>             proposed in my earlier mail
>>>>>             using a test case inspired by the Infinispan code.
>>>>>             NPE occurs when running the class initializer for
>>>>>             PrimitiveClassDescImpl
>>>>>             Interestingly, PrimitiveClassDescImpl?is "forcefully"
>>>>>             initialized by MetaspaceShared::link_shared_classes().
>>>>>
>>>>>             I couldn't get a stack trace so I relied on exception
>>>>>             logs (using -Xlog:exceptions=trace) to find the cause
>>>>>             which indicate following frames on the stack:
>>>>>
>>>>>             [0]
>>>>>             jdk/internal/constant/MethodTypeDescImpl::validateArgument(Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/ClassDesc;?@
>>>>>             bci 1
>>>>>             [1]
>>>>>             jdk/internal/constant/MethodTypeDescImpl::ofTrusted(Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljdk/internal/constant/MethodTypeDescImpl;?@
>>>>>             bci 27
>>>>>             [2]
>>>>>             java/lang/constant/ConstantDescs::ofConstantBootstrap(Ljava/lang/constant/ClassDesc;Ljava/lang/String;Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/DirectMethodHandleDesc;?@
>>>>>             bci 47
>>>>>             [3] java/lang/constant/ConstantDescs::<clinit>?@ bci 664
>>>>>             [4]
>>>>>             jdk/internal/constant/PrimitiveClassDescImpl::<init>(Ljava/lang/String;)V?@
>>>>>             bci 1
>>>>>             [5]
>>>>>             jdk/internal/constant/PrimitiveClassDescImpl::<clinit>(Ljava/lang/String;)V?@
>>>>>             bci 6
>>>>>
>>>>>             Notice?that invocation of
>>>>>             PrimitiveClassDescImpl::<clinit> results in
>>>>>             initialization of ConstantDescs?class (see frame 3).
>>>>>             ConstantDescs::<clinit>?@ 664 corresponds to following
>>>>>             java code:
>>>>>
>>>>>             ? public static final DirectMethodHandleDesc
>>>>>             BSM_CLASS_DATA_AT
>>>>>             ? ? ? ? ? = ofConstantBootstrap(CD_MethodHandles,
>>>>>             "classDataAt",
>>>>>             ? ? ? ? ? ? CD_Object, CD_int);
>>>>>
>>>>>             The last parameter CD_int is initialized as:
>>>>>
>>>>>             ? public static final ClassDesc CD_int =
>>>>>             PrimitiveClassDescImpl.CD_int;
>>>>>
>>>>>             So, its value is obtained from
>>>>>             PrimitiveClassDescImpl.CD_int?which hasn't been
>>>>>             initialized properly yet. As a result
>>>>>             ConstantDescs::CD_int is assigned?null which results
>>>>>             in MethodTypeDescImpl::validateArgument throwing NPE
>>>>>             later.
>>>>>             There is a clear class initialization circularity
>>>>>             involving PrimitiveClassDescImpl and ConstantDescs,
>>>>>             and the result depends on which class gets initialized
>>>>>             first.
>>>>>
>>>>>             Without my patch this issue is not seen because
>>>>>             PrimitiveClassDescImpl has already been initialized by
>>>>>             the time MetaspaceShared::link_shared_classes()?is called.
>>>>>             Its initialization is triggered by the call to
>>>>>             MethodType::createArchivedObjects().
>>>>>             It also explains why my patch introduced this issue
>>>>>             because it effectively moved the call to
>>>>>             MethodType::createArchivedObjects() after
>>>>>             MetaspaceShared::link_shared_classes().
>>>>>
>>>>>             [0]
>>>>>             https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>>>>             <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>>>>
>>>>>             Thanks,
>>>>>             - Ashutosh Mehra
>>>>>
>>>>>
>>>>>             On Wed, Sep 11, 2024 at 3:12?PM Ashutosh Mehra
>>>>>             <asmehra at redhat.com> wrote:
>>>>>
>>>>>                 Regarding the WrongMethodTypeException that I
>>>>>                 mentioned in my previous email (see pt 3),
>>>>>                 this exception happens when lambda proxy class
>>>>>                 attempts to invoke the MethodHandle it obtained
>>>>>                 from the classData:
>>>>>
>>>>>                 public void accept(java.lang.Object);
>>>>>                 ? ? descriptor: (Ljava/lang/Object;)V
>>>>>                 ? ? flags: (0x0001) ACC_PUBLIC
>>>>>                 ? ? Code:
>>>>>                 ? ? ? stack=3, locals=2, args_size=2
>>>>>                 ? ? ? ? ?0: ldc ? ? ? ? ? #26 ? ? ? ? ? ? ? ? //
>>>>>                 Dynamic #0:_:Ljava/lang/invoke/MethodHandle;
>>>>>                 ? ? ? ? ?2: aload_0
>>>>>                 ? ? ? ? ?3: getfield ? ? ?#13 ? ? ? ? ? ? ? ? //
>>>>>                 Field
>>>>>                 arg$1:Lorg/wildfly/security/WildFlyElytronBaseProvider;
>>>>>                 ? ? ? ? ?6: aload_1
>>>>>                 ? ? ? ? ?7: checkcast ? ? #28 ? ? ? ? ? ? ? ? //
>>>>>                 class java/security/Provider$Service
>>>>>                 ? ? ? ? 10: invokevirtual #34 ? ? ? ? ? ? ? ? //
>>>>>                 Method
>>>>>                 java/lang/invoke/MethodHandle.invokeExact:(Lorg/wildfly/security/WildFlyElytronBaseProvider;Ljava/security/Provider$Service;)V
>>>>>                 ? ? ? ? 13: return
>>>>>
>>>>>                 The scenario is during the assembly phase as part
>>>>>                 of the indy resolution the MethodHandle for which
>>>>>                 the exception is thrown gets created.
>>>>>                 Normally MethodHandle's type gets added in
>>>>>                 MethodType::internTable but by the time indy
>>>>>                 resolution happens, JVM has already taken
>>>>>                 snapshot of the MethodType::internTable through an
>>>>>                 upcall to MethodType::createArchivedObjects().
>>>>>                 As a result the AOTCache ends up with the
>>>>>                 MethodType object which is not in
>>>>>                 AOTHolder.archivedMethodTypes.
>>>>>
>>>>>                 During the production run, when the jvm invokes
>>>>>                 the MethodHandle, it searches for the MethodType
>>>>>                 corresponding to the signature passed at the callsite.
>>>>>                 As expected, it fails to find it in the
>>>>>                 AOTHolder.archivedMethodTypes, so it creates a new
>>>>>                 instance of the MethodType.
>>>>>                 But Invokers.checkExactType() relies on the
>>>>>                 MethodHandle's?type to be the same object as the
>>>>>                 MethodType object passed as parameter.
>>>>>
>>>>>                 static void checkExactType(MethodHandle mhM,
>>>>>                 MethodType expected) {
>>>>>                 ? ? MethodType targetType = mh.type();
>>>>>                 ? ? ? ? if (targetType != expected)
>>>>>                 ? ? ? ? ? ? throw
>>>>>                 newWrongMethodTypeException(targetType, expected);
>>>>>                 ? ? }
>>>>>
>>>>>                 Hence, it throws WrongMethodTypeException?though
>>>>>                 the two MT objects have the same signature.
>>>>>
>>>>>                 To handle this scenario, I changed the order of
>>>>>                 indy resolution and upcall to
>>>>>                 MethodType::createArchivedObjects()?as:
>>>>>
>>>>>                 diff --git
>>>>>                 a/src/hotspot/share/cds/metaspaceShared.cpp
>>>>>                 b/src/hotspot/share/cds/metaspaceShared.cpp
>>>>>                 index df4bcadefa3..457716cac5b 100644
>>>>>                 --- a/src/hotspot/share/cds/metaspaceShared.cpp
>>>>>                 +++ b/src/hotspot/share/cds/metaspaceShared.cpp
>>>>>                 @@ -751,6 +751,20 @@ void
>>>>>                 MetaspaceShared::link_shared_classes(bool
>>>>>                 jcmd_request, TRAPS) {
>>>>>                 ? ?if (CDSConfig::is_dumping_final_static_archive()) {
>>>>>                 ?FinalImageRecipes::apply_recipes(CHECK);
>>>>>                 ? ?}
>>>>>                 +
>>>>>                 +#if INCLUDE_CDS_JAVA_HEAP
>>>>>                 + ?if (CDSConfig::is_dumping_invokedynamic()) {
>>>>>                 + ? ?// This makes sure that the MethodType and
>>>>>                 MethodTypeForm tables won't be updated
>>>>>                 + ? ?// concurrently when we are saving their
>>>>>                 contents into a side table.
>>>>>                 +
>>>>>                 ?assert(CDSConfig::allow_only_single_java_thread(),
>>>>>                 "Required");
>>>>>                 +
>>>>>                 + ? ?JavaValue result(T_VOID);
>>>>>                 + ?JavaCalls::call_static(&result,
>>>>>                 vmClasses::MethodType_klass(),
>>>>>                 + vmSymbols::createArchivedObjects(),
>>>>>                 + vmSymbols::void_method_signature(),
>>>>>                 + CHECK);
>>>>>                 + ?}
>>>>>                 +#endif
>>>>>                 ?}
>>>>>                 Note that indy resolution happens as part of
>>>>>                 FinalImageRecipes::apply_recipes(CHECK) which is
>>>>>                 now invoked before the upcall to
>>>>>                 createArchivedObjects().
>>>>>                 With this change I am able to run the application
>>>>>                 without any exceptions.
>>>>>                 My complete patch can be seen here:
>>>>>                 https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>>>>                 <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>>>>                 I will do more testing with this patch.
>>>>>
>>>>>                 @Ioi Lam <mailto:ioi.lam at oracle.com>?do you have
>>>>>                 any feedback on this patch.
>>>>>
>>>>>                 Thanks,
>>>>>                 - Ashutosh Mehra
>>>>>
>>>>>
>>>>>
>>>>>                 On Wed, Sep 11, 2024 at 10:14?AM Ashutosh Mehra
>>>>>                 <asmehra at redhat.com> wrote:
>>>>>
>>>>>                     Hi Andrew,
>>>>>                     Thanks for sharing the initial investigation.
>>>>>                     I have been looking into this and have a few
>>>>>                     of things to add to your analysis:
>>>>>
>>>>>                     1.? As you mentioned the classData for the
>>>>>                     lambda
>>>>>                     class?WildFlyElytronBaseProvider$$Lambda is null.
>>>>>                     The classData is stored in the mirror object
>>>>>                     of the InstanceKlass when the class is defined
>>>>>                     through?JVM_LookupDefineClass.
>>>>>                     However, when we create the scratch mirror
>>>>>                     object (which get stored in the AOT cache) the
>>>>>                     classData is not populated.
>>>>>                     See
>>>>>                     https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp#L1128-L1131
>>>>>                     <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp*L1128-L1131__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhbKjzG3gw$>
>>>>>
>>>>>                     Handle classData; // set to null. Will be
>>>>>                     reinitialized at runtime
>>>>>                     ? Handle mirror;
>>>>>                     ? Handle comp_mirror;
>>>>>                     ? allocate_mirror(k, /*is_scratch=*/true,
>>>>>                     protection_domain, classData, mirror,
>>>>>                     comp_mirror, CHECK);
>>>>>
>>>>>                     So this explains why the call to
>>>>>                     classData(caller.lookupClass())returned null.
>>>>>
>>>>>                     2. In the mainline there is a check
>>>>>                     in?InnerClassLambdaMetafactory.java for the
>>>>>                     particular code pattern used by the application.
>>>>>                     If this code pattern is found then the lambda
>>>>>                     proxy class is not included in the CDS archive.
>>>>>                     See
>>>>>                     https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L163-L170
>>>>>                     <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L163-L170__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZl2S9tQg$>
>>>>>                     and
>>>>>                     https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L246
>>>>>                     <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L246__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhYsI3Xx0g$>
>>>>>
>>>>>                     ? ? ? // If the target class invokes a
>>>>>                     protected method inherited from a
>>>>>                     ? ? ? ? // superclass in a different package,
>>>>>                     or does 'invokespecial', the
>>>>>                     ? ? ? ? // lambda class has no access to the
>>>>>                     resolved method, or does
>>>>>                     ? ? ? ? // 'invokestatic' on a hidden class
>>>>>                     which cannot be resolved by name.
>>>>>                     ? ? ? ? // Instead, we need to pass the live
>>>>>                     implementation method handle to
>>>>>                     ? ? ? ? // the proxy class to invoke directly.
>>>>>                     (javac prefers to avoid this
>>>>>                     ? ? ? ? // situation by generating bridges in
>>>>>                     the target class)
>>>>>                     useImplMethodHandle =
>>>>>                     (Modifier.isProtected(implInfo.getModifiers()) &&
>>>>>                     ?!VerifyAccess.isSamePackage(targetClass,
>>>>>                     implInfo.getDeclaringClass())) ||
>>>>>                     ? ? ? ?implKind ==
>>>>>                     MethodHandleInfo.REF_invokeSpecial ||
>>>>>                     ? ? ? ?implKind ==
>>>>>                     MethodHandleInfo.REF_invokeStatic &&
>>>>>                     implClass.isHidden();
>>>>>
>>>>>                     In premain lambda proxy classes get included
>>>>>                     in the AOT cache as a result of indy
>>>>>                     resolution and that mechanism doesn't have
>>>>>                     this kind of check.
>>>>>
>>>>>                     3. For the null classData problem mentioned
>>>>>                     above, I tried to fix it by storing classData
>>>>>                     in the scratch mirror using the following patch:
>>>>>
>>>>>                     diff --git
>>>>>                     a/src/hotspot/share/classfile/javaClasses.cpp
>>>>>                     b/src/hotspot/share/classfile/javaClasses.cpp
>>>>>                     index bd8141adbcc..41766e98093 100644
>>>>>                     --- a/src/hotspot/share/classfile/javaClasses.cpp
>>>>>                     +++ b/src/hotspot/share/classfile/javaClasses.cpp
>>>>>                     @@ -1094,9 +1094,9 @@ void
>>>>>                     java_lang_Class::create_mirror(Klass* k,
>>>>>                     Handle class_loader,
>>>>>                     ? ? ?}
>>>>>                     ? ? ?if (CDSConfig::is_dumping_heap()) {
>>>>>                     ? ? ? ?if
>>>>>                     (CDSConfig::is_dumping_protection_domains()) {
>>>>>                     - ?create_scratch_mirror(k, protection_domain,
>>>>>                     CHECK);
>>>>>                     + ?create_scratch_mirror(k, protection_domain,
>>>>>                     classData, CHECK);
>>>>>                     ? ? ? ?} else {
>>>>>                     - ?create_scratch_mirror(k, Handle() /* null
>>>>>                     protection_domain*/, CHECK);
>>>>>                     + ?create_scratch_mirror(k, Handle() /* null
>>>>>                     protection_domain*/, classData, CHECK);
>>>>>                     ? ? ? ?}
>>>>>                     ? ? ?}
>>>>>                     ? ?} else {
>>>>>                     @@ -1117,7 +1117,7 @@ void
>>>>>                     java_lang_Class::create_mirror(Klass* k,
>>>>>                     Handle class_loader,
>>>>>                     ?// Note: we archive the "scratch mirror"
>>>>>                     instead of k->java_mirror(), because the
>>>>>                     ?// latter may contain dumptime-specific
>>>>>                     information that cannot be archived
>>>>>                     ?// (e.g., ClassLoaderData*, or static fields
>>>>>                     that are modified by Java code execution).
>>>>>                     -void
>>>>>                     java_lang_Class::create_scratch_mirror(Klass*
>>>>>                     k, Handle protection_domain, TRAPS) {
>>>>>                     +void
>>>>>                     java_lang_Class::create_scratch_mirror(Klass*
>>>>>                     k, Handle protection_domain, Handle classData,
>>>>>                     TRAPS) {
>>>>>                     ? ?if (k->class_loader() != nullptr &&
>>>>>                     ?k->class_loader() !=
>>>>>                     SystemDictionary::java_platform_loader() &&
>>>>>                     ?k->class_loader() !=
>>>>>                     SystemDictionary::java_system_loader()) {
>>>>>                     @@ -1125,9 +1125,11 @@ void
>>>>>                     java_lang_Class::create_scratch_mirror(Klass*
>>>>>                     k, Handle protection_domain,
>>>>>                     ? ? ?return;
>>>>>                     ? ?}
>>>>>
>>>>>                     - ?Handle classData; // set to null. Will be
>>>>>                     reinitialized at runtime
>>>>>                     + ?//Handle classData; // set to null. Will be
>>>>>                     reinitialized at runtime
>>>>>                     ? ?Handle mirror;
>>>>>                     ? ?Handle comp_mirror;
>>>>>                     ? ?allocate_mirror(k, /*is_scratch=*/true,
>>>>>                     protection_domain, classData, mirror,
>>>>>                     comp_mirror, CHECK);
>>>>>
>>>>>                     ? ?if (comp_mirror() != nullptr) {
>>>>>                     diff --git
>>>>>                     a/src/hotspot/share/classfile/javaClasses.hpp
>>>>>                     b/src/hotspot/share/classfile/javaClasses.hpp
>>>>>                     index bc49a0861a7..7ec2a2556dd 100644
>>>>>                     --- a/src/hotspot/share/classfile/javaClasses.hpp
>>>>>                     +++ b/src/hotspot/share/classfile/javaClasses.hpp
>>>>>                     @@ -263,7 +263,7 @@ class java_lang_Class :
>>>>>                     AllStatic {
>>>>>
>>>>>                     ? ?// Archiving
>>>>>                     ? ?static void
>>>>>                     serialize_offsets(SerializeClosure* f)
>>>>>                     NOT_CDS_RETURN;
>>>>>                     - ?static void create_scratch_mirror(Klass* k,
>>>>>                     Handle protection_domain, TRAPS)
>>>>>                     NOT_CDS_JAVA_HEAP_RETURN;
>>>>>                     + ?static void create_scratch_mirror(Klass* k,
>>>>>                     Handle protection_domain, Handle classData,
>>>>>                     TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>>>>>                     ? ?static bool restore_archived_mirror(Klass
>>>>>                     *k, Handle class_loader, Handle module,
>>>>>                     ? ? ? ? ? ? ? ?Handle protection_domain,
>>>>>                     ? ? ? ? ? ? ? ?TRAPS)
>>>>>                     NOT_CDS_JAVA_HEAP_RETURN_(false);
>>>>>
>>>>>                     But this resulted in a different exception:
>>>>>
>>>>>                     Exception in thread "main"
>>>>>                     java.lang.ExceptionInInitializerError
>>>>>                     at com.redhat.leyden.Main.main(Main.java:7)
>>>>>                     Caused by:
>>>>>                     java.lang.invoke.WrongMethodTypeException:
>>>>>                     handle's method type
>>>>>                     (WildFlyElytronBaseProvider,Service)void but
>>>>>                     found (WildFlyElytronBaseProvider,Service)void
>>>>>                     at
>>>>>                     java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>>>>>                     at
>>>>>                     java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>>>>>                     at
>>>>>                     java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
>>>>>                     at
>>>>>                     org.wildfly.security.WildFlyElytronBaseProvider$$Lambda/0x80000000c.accept(Unknown
>>>>>                     Source)
>>>>>                     at
>>>>>                     org.wildfly.security.WildFlyElytronBaseProvider.putMakedPasswordImplementations(WildFlyElytronBaseProvider.java:112)
>>>>>                     at
>>>>>                     org.wildfly.security.WildFlyElytronBaseProvider.putPasswordImplementations(WildFlyElytronBaseProvider.java:107)
>>>>>                     at
>>>>>                     org.wildfly.security.password.WildFlyElytronPasswordProvider.<init>(WildFlyElytronPasswordProvider.java:43)
>>>>>                     at
>>>>>                     org.wildfly.security.password.WildFlyElytronPasswordProvider.<clinit>(WildFlyElytronPasswordProvider.java:36)
>>>>>                     ... 1 more
>>>>>
>>>>>                     The exception message is strange because the
>>>>>                     handle's method type and the expected type are
>>>>>                     both symbolically the same.
>>>>>                     I am debugging this exception at the moment.
>>>>>                     Thanks,
>>>>>                     - Ashutosh Mehra
>>>>>
>>>>>
>>>>>                     On Wed, Sep 11, 2024 at 6:03?AM Andrew Dinn
>>>>>                     <adinn at redhat.com> wrote:
>>>>>
>>>>>                         Oops, sorry, I debugged this a few days
>>>>>                         ago! Correction to a few details:
>>>>>
>>>>>                         On 11/09/2024 10:39, Andrew Dinn wrote:
>>>>>                         > A crash due to an NPE was observed in
>>>>>                         the Infinispan (Data Grid) server
>>>>>                         > app when deployed using the Leyden EA.
>>>>>                         The crash still manifests with
>>>>>                         > the latest premain code. The crash
>>>>>                         happens below an application call
>>>>>                         > which employs a method reference as argument
>>>>>                         >
>>>>>                         >
>>>>>                         putMakedPasswordImplementations(this::putService,
>>>>>                         this);
>>>>>
>>>>>                         The called method in turn calls
>>>>>                         consumer.accept
>>>>>
>>>>>                         ?consumer.accept(new Service(provider,
>>>>>                         PASSWORD_FACTORY_TYPE, algorithm,
>>>>>                         "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>>>>                         emptyList,
>>>>>                         emptyMap));
>>>>>
>>>>>                         which enters enters
>>>>>                         MethodHandleNative::linkDynamicConstant()
>>>>>
>>>>>                         > Debugging shows that the call to
>>>>>                         linkDynamicConstant() returns null.
>>>>>                         >
>>>>>                         > A simple reproducer for the problem is
>>>>>                         available as a maven project on
>>>>>                         > github:
>>>>>                         >
>>>>>                         >
>>>>>                         https://github.com/tristantarrant/elytron-leyden
>>>>>                         <https://urldefense.com/v3/__https://github.com/tristantarrant/elytron-leyden__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZaZr1akQ$>
>>>>>                         >
>>>>>                         > The ReadMe provides an explanation of
>>>>>                         how to reproduce the problem. I
>>>>>                         > did so and the debugged to find out some
>>>>>                         of the details of what is
>>>>>                         > happening (see below) but did not fully
>>>>>                         clarify the problem. Help from
>>>>>                         > someone more conversant with the ins and
>>>>>                         outs of method handle
>>>>>                         > bootstraps in premain would be welcome.
>>>>>                         Details follow.
>>>>>                         >
>>>>>                         > regards,
>>>>>                         >
>>>>>                         >
>>>>>                         > Andrew Dinn
>>>>>                         > -----------
>>>>>                         >
>>>>>                         > I downloaded the git repo and attached
>>>>>                         the Java sources using Maven command
>>>>>                         >
>>>>>                         >? ? $ mvn dependency:sources
>>>>>                         >
>>>>>                         > Having manifested the crash by following
>>>>>                         the instructions in the README
>>>>>                         > I reran the leyden JVM under gdb using
>>>>>                         the following commands to enable
>>>>>                         > Java debugging
>>>>>                         >
>>>>>                         > $ gdb ${LEYDEN_HOME}/bin/java
>>>>>                         > (gdb) cd /path/to/mvn/project
>>>>>                         > (gdb) run
>>>>>                         >
>>>>>                         -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
>>>>>
>>>>>                         > -classpath
>>>>>                         >
>>>>>                         /home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/2.5.1.
>>>>>                         <https://urldefense.com/v3/__http://2.5.1.__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhauJ-RjcQ$>Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar
>>>>>                         -XX:CacheDataStore=elytron.aot
>>>>>                         com.redhat.leyden.Main
>>>>>                         >
>>>>>                         > The problem manifests at
>>>>>                         WildflyElytronBaseProvider.java:112 in method
>>>>>                         >
>>>>>                         WildflyElytronBaseProvider::putMakedPasswordImplementations
>>>>>
>>>>>                         ? ? ?static void
>>>>>                         putMakedPasswordImplementations(Consumer<Service>
>>>>>
>>>>>                         consumer, Provider provider) {
>>>>>                         ? ? ? ? ?for (String algorithm :
>>>>>                         MASKED_ALGORITHMS) {
>>>>>                         ?consumer.accept(new Service(provider,
>>>>>                         PASSWORD_FACTORY_TYPE, algorithm,
>>>>>                         "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>>>>                         emptyList,
>>>>>                         emptyMap)); <== NPE under this call
>>>>>                         ? ? ? ? ?}
>>>>>
>>>>>
>>>>>                         > The source code for this method can be
>>>>>                         found in the following source jar
>>>>>                         >
>>>>>                         >
>>>>>                         >
>>>>>                         ${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar
>>>>>                         >
>>>>>                         > (where M2_REPO will normally be
>>>>>                         ~/.m2/repository)
>>>>>                         >
>>>>>                         > Stepping into accept eventually enters
>>>>>                         MethodHandleNative::linkDynamicConstant
>>>>>                         > which in turn enters into
>>>>>                         ConstantBootstraps.makeConstant(). The caller
>>>>>                         > Class at this point is a lambda class
>>>>>                         which prints as
>>>>>                         >
>>>>>                         org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c
>>>>>                         >
>>>>>                         > Several steps further the code enters
>>>>>                         BootstrapMethodInvoker::invoke
>>>>>                         > (below the app method call but via 3
>>>>>                         hidden frames) with bootstrapMethod
>>>>>                         > bound to a DirectMethodHandle. After
>>>>>                         several more steps this enters
>>>>>                         > DirectMethodHandle$Holder.invokeStatic
>>>>>                         which in turn calls
>>>>>                         >
>>>>>                         MethodHandles::classData(Lookup,String,Class).
>>>>>                         >
>>>>>                         > At this point caller is a
>>>>>                         MethodHandleLookup for the lambda class
>>>>>                         > Lambda/0x800000000c mentioned above. The
>>>>>                         following call
>>>>>                         >
>>>>>                         >? ???????? Object classdata =
>>>>>                         classData(caller.lookupClass());
>>>>>                         >
>>>>>                         > returns null to
>>>>>                         DirectMethodHandle$Holder.invokeStatic
>>>>>                         which pops the
>>>>>                         > same result back out to
>>>>>                         BootstrapMethodInvoker::invoke at line 90
>>>>>                         >
>>>>>                         >? ??????????????? if (type instanceof
>>>>>                         Class<?> c) {
>>>>>                         > result = bootstrapMethod.invoke(caller,
>>>>>                         name, c);
>>>>>                         > <== null
>>>>>                         >
>>>>>                         > This null result pops back out as the
>>>>>                         value for the call to
>>>>>                         > BootstrapMethodInvoker.invoke(),
>>>>>                         ConstantBootstraps.makeConstant() and
>>>>>                         > MethodHandleNative::linkDynamicConstant().
>>>>>                         >
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240923/acaec0ab/attachment.htm>

From asmehra at redhat.com  Tue Sep 24 15:24:58 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Tue, 24 Sep 2024 11:24:58 -0400
Subject: premain: Crash in Infinispan server code caused by NPE under
 MethodHandleNative::linkDynamicConstant
In-Reply-To: <9ec705a7-4fa5-40f8-8685-b49c54ab4418@oracle.com>
References: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
 <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>
 <CAKt0pySztvwsadtrqjai6XwakAWq_v_o8men4aopLo4X-0azyQ@mail.gmail.com>
 <CAKt0pyQ44E+npyUW35Zhxg+PfBgF2yuNgS61gj1GGj=aLGTJXw@mail.gmail.com>
 <CAKt0pyT48uPH6rUL7bEJ2rtWqNdNL34DWBJ2SDaHwYfVxURnQw@mail.gmail.com>
 <0d22d580-39a1-4105-a50e-8a74a555090d@oracle.com>
 <CAKt0pyRYBNtkLzVoAfDHWE=4e+9efZFb+xKYZv-d3LpDAU4qZg@mail.gmail.com>
 <da797fe2-137c-4fc7-a67c-3b595c0c63f2@oracle.com>
 <CAKt0pyRj8_mDiH58v10sqXNHA4iHja6-7D9N_S2VW9rhESPcTw@mail.gmail.com>
 <45e62b78-bbde-4ba5-8b20-77125d14b908@oracle.com>
 <4dc70b95-f014-44f1-acfb-027c8e28e81d@oracle.com>
 <CAKt0pyQ8T+-yZQ1UJBewcc_DXTMRymNRSp3cz4xCZf54XUhw+g@mail.gmail.com>
 <9ec705a7-4fa5-40f8-8685-b49c54ab4418@oracle.com>
Message-ID: <CAKt0pyTQXoW82Dx=BRFx93_wm6dEiCcncT66mDOHGXt4GqiE0Q@mail.gmail.com>

Hi Ioi,
Thanks for sharing the code changes.
The wildfly-elytron testcase passes with these changes, but I still get the
NPE in PrimitiveClassDescImpl.<clinit> when running with my own testcase.
I have pushed my test case to a repo [2], so you can try it as well. I have
added some instructions to the Readme file.
Let me know if you face any issues in running the test case.

[2] https://github.com/ashu-mehra/leyden-testcase/

Thanks,
- Ashutosh Mehra


On Mon, Sep 23, 2024 at 11:24?PM <ioi.lam at oracle.com> wrote:

> Hi Ashutosh,
>
> Thank you again for the summary of the issues.
> I looked at the call paths again and I think two calls need to be moved
>
> (1) MethodType::createArchivedObjects() needs to be called after we have
> executed all other Java code. So I put it before the
> StringTable::allocate_shared_strings_array() call.
>
> (2) SystemDictionary::get_all_method_handle_intrinsics() needs to be done
> inside the safepoint, so it can be sure to find all the method handle
> intrinsic methods (which can be generated as the side effect of Java code
> execution).
>
> I also added the archiving of the classData field.
>
> See my temporary change at
> https://github.com/iklam/jdk/commit/eafaa9731ae89b93f3e20702fc4d5a12cb070149
>
> With this change, I am able to successfully run the test in
> https://github.com/tristantarrant/elytron-leyden . I also modified the
> LambdaWithUseImplMethodHandle.java test to add a similar test scenario.
>
> I agree with you that the code in
> AOTClassInitializer::is_forced_preinit_class() is too ad-hoc, and might
> change the order of class initialization. In the upstream PR, I have
> changed the code to only assert that the listed of classes has been
> initialized:
>
>
> https://github.com/iklam/jdk/blob/5cc31ed60cc9597d63b86f20b95c964d4d1a6b84/src/hotspot/share/cds/aotClassInitializer.cpp#L66-L84
>
> I will try to merge this version of the code back to the Leyden repo.
>
> I think by doing this, we can avoid direct manipulation of the class-init
> order of the core-library classes. Instead, we just make sure that we
> execute enough "normal" code during the assembly phase to ensure that these
> classes are initialized in their normal order.
>
> What do you think?
>
> Thanks
>
> - Ioi
>
>
> On 9/19/24 8:05 PM, Ashutosh Mehra wrote:
>
> Upon further investigation, it seems a simple patch might fix the problem
>> with classData.
>>
>> I tested with
>> test/hotspot/jtreg/runtime/cds/appcds/LambdaWithUseImplMethodHandle.java by
>> running jtreg with -javaoptions:-XX:+AOTClassLinking
>> Without the patch, I'd get a NullPointerException. With the patch, the
>> test passes.
>>
>> It looks like classData is not treated as a static field of the class,
>> but rather an instance field in the mirror. So classData wasn't copied by
>> the loop in HeapShared::copy_preinitialized_mirror().
>>
>> Ashutosh, could you try it this fixes the crash on your side?
>>
>> Thanks
>>
>> - Ioi
>>
>> diff --git a/src/hotspot/share/cds/heapShared.cpp
>> b/src/hotspot/share/cds/heapShared.cpp
>> index 0e70778f057..62cf142f67a 100644
>> --- a/src/hotspot/share/cds/heapShared.cpp
>> +++ b/src/hotspot/share/cds/heapShared.cpp
>> @@ -634,6 +634,8 @@ void HeapShared::copy_preinitialized_mirror(Klass*
>> orig_k, oop orig_mirror, oop
>>      }
>>    }
>>
>> +  java_lang_Class::set_class_data(m,
>> java_lang_Class::class_data(orig_mirror));
>> +
>>    // Class::reflectData use SoftReference, which cannot be archived. Set
>> it
>>    // to null and it will be recreated at runtime.
>>    java_lang_Class::set_reflection_data(m, nullptr);
>>
>
> Hi Ioi,
>
> This patch effectively does the same thing as my initial patch for storing
> classData in the scratch mirror object [1].
>
> At this point I think it would be useful to do a quick recap of the issues
> mentioned in this thread. There are 3 issues I have encountered so far.
> I was initially thinking of a solution that would cover all these
> problems, but looking at these again, I feel these are orthogonal to each
> other:
>
> 1. The missing classData in scratch mirrors which can be fixed by either
> of the patches shared in this thread. They achieve the same goal and I
> don't have any strong preference for any of them.
>
> 2. After fixing the classData, I ran into  WrongMethodTypeException issue
> [2] which I fixed by exchanging the order of indy resolution with the call
> to MethodType::createArchivedObjects [3].
> This change makes sense because we want to make sure all the MethodType
> objects that can be archived are in MethodType internTable before calling
> MethodType::createArchivedObjects.
> I am not sure why LambdaWithUseImplMethodHandle.java didn't throw the
> WrongMethodTypeException, as the Infinispan code does.
>
> 3. After fixing the WrongMethodTypeException I hit NPE due to the class
> initialization cycle between PrimitiveClassDescImpl and ConstantDescs [4]
> in one of my own testcase.
> We are looking for a solution to this problem. I am not sure if we can
> break this cycle by refactoring the Java code.
> Nevertheless, I think it is fair to assume that there is no Java code that
> can initiate initialization of PrimitiveClassDescImpl before ConstantDescs,
> otherwise we would have hit the NPE earlier.
> So if ConstantDescs is always expected to be initialized before
> PrimitiveClassDescImpl then I think the VM code should also maintain this
> assumption.
> Now this brings us back to the forceful initialization done by the VM
> during the assembly phase based on the forced_preinit_classes list in
> aotClassInitializer.cpp:
>
>     // TODO:
>     // This is needed since JDK-8338532. Without this, when
>     // archived heap objects are used, the class init order is not
>     // expected by the jdk/internal/constant bootstrap code and we
>     // will get a null pointer exception.
>     //
>     // When bootstraping has intricated/fragile order, it's probably
>     // better to archive all related classes in an initialized state
>     // (i.e., take a snapshot). The existing approach in
>     // heapShared::resolve_or_init_classes_for_subgraph_of() won't work.
>     "jdk/internal/constant/PrimitiveClassDescImpl",
>     "jdk/internal/constant/ReferenceClassDescImpl",
>     "java/lang/constant/ConstantDescs",
>     "sun/invoke/util/Wrapper",
>
> I wonder why we need to explicitly add  PrimitiveClassDescImpl and
> ReferenceClassDescImpl in this list.
> Initialization of ConstantDescs would anyway trigger the initialization
> of PrimitiveClassDescImpl and ReferenceClassDescImpl.
> So if we only keep the entry for ConstantDescs and remove
> PrimitiveClassDescImpl and ReferenceClassDescImpl from this list,
> we can be sure that the forceful initialization by the VM would maintain
> the same order of initialization as guided by the Java code,
> and we will not hit the NPE when initializing PrimitiveClassDescImpl during
> the assembly phase.
> Does this make sense?
>
>
> [1]
> https://mail.openjdk.org/pipermail/leyden-dev/2024-September/000994.html
> [2]
> https://mail.openjdk.org/pipermail/leyden-dev/2024-September/000997.html
> [3]
> https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!KvYLs_vG0a4GO3ltinXQkxBG1kMhCAvmmM6MwODoKzOhhVjzNL80S_0mBzYvYyhYPQnGmXhAXSw78Q$>
> [4]
> https://mail.openjdk.org/pipermail/leyden-dev/2024-September/001018.html
>
> Thanks,
> - Ashutosh Mehra
>
>
> On Thu, Sep 19, 2024 at 8:51?PM <ioi.lam at oracle.com> wrote:
>
>> Upon further investigation, it seems a simple patch might fix the problem
>> with classData.
>>
>> I tested with
>> test/hotspot/jtreg/runtime/cds/appcds/LambdaWithUseImplMethodHandle.java by
>> running jtreg with -javaoptions:-XX:+AOTClassLinking
>> Without the patch, I'd get a NullPointerException. With the patch, the
>> test passes.
>>
>> It looks like classData is not treated as a static field of the class,
>> but rather an instance field in the mirror. So classData wasn't copied by
>> the loop in HeapShared::copy_preinitialized_mirror().
>>
>> Ashutosh, could you try it this fixes the crash on your side?
>>
>> Thanks
>>
>> - Ioi
>>
>> diff --git a/src/hotspot/share/cds/heapShared.cpp
>> b/src/hotspot/share/cds/heapShared.cpp
>> index 0e70778f057..62cf142f67a 100644
>> --- a/src/hotspot/share/cds/heapShared.cpp
>> +++ b/src/hotspot/share/cds/heapShared.cpp
>> @@ -634,6 +634,8 @@ void HeapShared::copy_preinitialized_mirror(Klass*
>> orig_k, oop orig_mirror, oop
>>      }
>>    }
>>
>> +  java_lang_Class::set_class_data(m,
>> java_lang_Class::class_data(orig_mirror));
>> +
>>    // Class::reflectData use SoftReference, which cannot be archived. Set
>> it
>>    // to null and it will be recreated at runtime.
>>    java_lang_Class::set_reflection_data(m, nullptr);
>>
>>
>>
>> On 9/19/24 12:51 PM, ioi.lam at oracle.com wrote:
>>
>>
>> On 9/19/24 7:44 AM, Ashutosh Mehra wrote:
>>
>> As I am cleaning up the code for upstreaming to mainline, I am going add
>>> an equivalent check in the C code to filter out these indy call sites, so
>>> they won't be resolved at all during the assembly phase. Otherwise, I will
>>> run into problems described in
>>> https://bugs.openjdk.org/browse/JDK-8290417
>>
>>
>> Thanks for the link to the bug. The scenario described in that bug is
>> exactly the same as the Infinispan case.
>> So if we filter out such cases during indy resolution then it should
>> resolve the Infinispan issue as well.
>>
>> A basic question: why can't CDS handle the lambda proxy class generated
>> in useImplMethodHandle mode?
>>
>> If I remember correctly, it has to do with the shape of dynamically
>> generated bytecode:
>>
>>   public void accept(java.lang.Object);
>>     Code:
>>        0: ldc #28 // Dynamic #0:_:Ljava/lang/invoke/MethodHandle;
>>        2: aload_0
>>        3: getfield #15 // Field arg$1:LTester;
>>        6: aload_1
>>        7: checkcast #30 // class java/lang/String
>>       10: invokevirtual #36 // Method
>> java/lang/invoke/MethodHandle.invokeExact:(LTester;Ljava/lang/String;)V
>>       13: return
>>
>> The result of the "ldc" was not symbolically encoded in the generated
>> class (as the generated class has no permission to access that method). So
>> the MethodHandle is stored as a binary object in the mirror of this
>> generated class (with the java.lang.Class::classData field).
>>
>> Plain CDS doesn't archive class mirrors, so the classData will be lost.
>>
>> With JEP 483, we should be able to preserve the classData, so I am not
>> sure why the useImplMethodHandle case is still failing. My plan is to
>> filter these out for now, but I will get back to it later when I have more
>> time.
>>
>> Thanks
>>
>> - Ioi
>>
>>
>>
>> Thanks,
>> - Ashutosh Mehra
>>
>>
>> On Thu, Sep 19, 2024 at 1:45?AM <ioi.lam at oracle.com> wrote:
>>
>>> Hi Ashutosh,
>>>
>>> I have some update:
>>>
>>> The original crash was caused by the "useImplMethodHandle" code in
>>> InnerClassLambdaMetafactory.java:
>>>
>>>         // If the target class invokes a protected method inherited from
>>> a
>>>         // superclass in a different package, or does 'invokespecial',
>>> the
>>>         // lambda class has no access to the resolved method, or does
>>>         // 'invokestatic' on a hidden class which cannot be resolved by
>>> name.
>>>         // Instead, we need to pass the live implementation method
>>> handle to
>>>         // the proxy class to invoke directly. (javac prefers to avoid
>>> this
>>>         // situation by generating bridges in the target class)
>>>         useImplMethodHandle =
>>> (Modifier.isProtected(implInfo.getModifiers()) &&
>>>                                !VerifyAccess.isSamePackage(targetClass,
>>> implInfo.getDeclaringClass())) ||
>>>                                implKind ==
>>> MethodHandleInfo.REF_invokeSpecial ||
>>>                                implKind ==
>>> MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>>>
>>> As I am cleaning up the code for upstreaming to mainline, I am going add
>>> an equivalent check in the C code to filter out these indy call sites, so
>>> they won't be resolved at all during the assembly phase. Otherwise, I will
>>> run into problems described in
>>> https://bugs.openjdk.org/browse/JDK-8290417
>>>
>>> Once I get the filtering code working, I will integrate it back to
>>> premain.
>>>
>>> >I am wondering if we can workaround class circularity issues by
>>> recording class initialization order
>>> >during training run and use that to guide the initialization during
>>> assembly phase.
>>>
>>> In the production run we take different paths than the training run
>>>
>>> (1) some classes are aot-initialized (especially the enums)
>>> (2) some classes make special CDS calls
>>>
>>> so I am not sure if it's possible to get the same initialization order
>>> as in the training run (or assembly phase).
>>>
>>> (more below)
>>> On 9/18/24 9:10 AM, Ashutosh Mehra wrote:
>>>
>>> Hi Ioi,
>>>
>>> I was having a similar circularity issue (but in production time) and I
>>>> just added enough classes to make the NPE go away.
>>>>
>>>
>>> I am wondering if you have a test case that reproduces the NPE which
>>> prompted you to add these classes:
>>>
>>>
>>> https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp#L65-L78
>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp*L65-L78__;Iw!!ACWV5N9M2RV99hQ!NYvqLbb_Ib2kSdm2fcYVLGby-AiB2TG7KtC1HQHVKLiM-_kRb5mOt8krV5IZfReaYZ0MPadDfa08hQ$>
>>>
>>> I commented this code and ran the tests under premain but didn't hit the
>>> NPE.
>>>
>>> I forgot what the problem was, but it happened for very simple cases.
>>>
>>> Thanks
>>>
>>> - Ioi
>>>
>>>
>>> Thanks,
>>> - Ashutosh Mehra
>>>
>>>
>>> On Tue, Sep 17, 2024 at 1:11?AM <ioi.lam at oracle.com> wrote:
>>>
>>>> Hi Ashutosh,
>>>>
>>>> So this looks like a potential bug (or feature) in the core lib code.
>>>> When CDS forcefully initializes a class in an unexpected (or untested)
>>>> order, the "initialization soup" fails.
>>>>
>>>> Perhaps a work-around would be to make some harmless calls at the place
>>>> where CDS was calling into MethodType.createArchivedObjects(). E.g., do
>>>> something like this:
>>>>
>>>> +    if (CDSConfig::is_dumping_invokedynamic()) {
>>>> +       // call into Java: jdk.internal.misc::warmupInvokeDynamic();
>>>> +   }
>>>>     // Rewrite and link classes
>>>>     log_info(cds)("Rewriting and linking classes ...");
>>>>
>>>> Maybe you can add a new Lambda expressions, MethodHandle invocations,
>>>> etc, that would hopefully cause PrimitiveClassDescImpl and friends to be
>>>> initialized in their natural order.
>>>>
>>>> Or call class.forName("java.lang.constant.ConstantDescs") ??
>>>>
>>>> BTW, you can see my comments in
>>>> AOTClassInitializer::is_forced_preinit_class():
>>>>
>>>>     // TODO:
>>>>     // This is needed since JDK-8338532. Without this, when
>>>>     // archived heap objects are used, the class init order is not
>>>>     // expected by the jdk/internal/constant bootstrap code and we
>>>>     // will get a null pointer exception.
>>>>     //
>>>>     // When bootstraping has intricated/fragile order, it's probably
>>>>     // better to archive all related classes in an initialized state
>>>>     // (i.e., take a snapshot). The existing approach in
>>>>     // heapShared::resolve_or_init_classes_for_subgraph_of() won't work.
>>>>     "jdk/internal/constant/PrimitiveClassDescImpl",
>>>>     "jdk/internal/constant/ReferenceClassDescImpl",
>>>>     "java/lang/constant/ConstantDescs",
>>>>     "sun/invoke/util/Wrapper",
>>>>
>>>> I was having a similar circularity issue (but in production time) and I
>>>> just added enough classes to make the NPE go away. For your test case, if
>>>> you manage to fix in in the assembly run but run into NPE in production
>>>> run, you might need to add more classes to this list. Yes, it's a hack :-(
>>>>
>>>>
>>>> Thanks
>>>>
>>>> - Ioi
>>>> On 9/13/24 7:05 PM, Ashutosh Mehra wrote:
>>>>
>>>> This is turning out to be a real example of class initialization soup!
>>>> As mentioned during the meeting, I am getting NPE in the assembly phase
>>>> when testing the patch [0] that I proposed in my earlier mail
>>>> using a test case inspired by the Infinispan code.
>>>> NPE occurs when running the class initializer for
>>>> PrimitiveClassDescImpl
>>>> Interestingly, PrimitiveClassDescImpl is "forcefully" initialized by
>>>> MetaspaceShared::link_shared_classes().
>>>>
>>>> I couldn't get a stack trace so I relied on exception logs (using
>>>> -Xlog:exceptions=trace) to find the cause which indicate following frames
>>>> on the stack:
>>>>
>>>> [0]
>>>> jdk/internal/constant/MethodTypeDescImpl::validateArgument(Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/ClassDesc; @
>>>> bci 1
>>>> [1]
>>>> jdk/internal/constant/MethodTypeDescImpl::ofTrusted(Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljdk/internal/constant/MethodTypeDescImpl; @
>>>> bci 27
>>>> [2]
>>>> java/lang/constant/ConstantDescs::ofConstantBootstrap(Ljava/lang/constant/ClassDesc;Ljava/lang/String;Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/DirectMethodHandleDesc; @
>>>> bci 47
>>>> [3] java/lang/constant/ConstantDescs::<clinit> @ bci 664
>>>> [4]
>>>> jdk/internal/constant/PrimitiveClassDescImpl::<init>(Ljava/lang/String;)V @
>>>> bci 1
>>>> [5]
>>>> jdk/internal/constant/PrimitiveClassDescImpl::<clinit>(Ljava/lang/String;)V @
>>>> bci 6
>>>>
>>>> Notice that invocation of PrimitiveClassDescImpl::<clinit> results in
>>>> initialization of ConstantDescs class (see frame 3).
>>>> ConstantDescs::<clinit> @ 664 corresponds to following java code:
>>>>
>>>>     public static final DirectMethodHandleDesc BSM_CLASS_DATA_AT
>>>>             = ofConstantBootstrap(CD_MethodHandles, "classDataAt",
>>>>             CD_Object, CD_int);
>>>>
>>>> The last parameter CD_int is initialized as:
>>>>
>>>>     public static final ClassDesc CD_int =
>>>> PrimitiveClassDescImpl.CD_int;
>>>>
>>>> So, its value is obtained from PrimitiveClassDescImpl.CD_int which
>>>> hasn't been initialized properly yet. As a result ConstantDescs::CD_int
>>>> is assigned null which results in MethodTypeDescImpl::validateArgument
>>>> throwing NPE later.
>>>> There is a clear class initialization circularity involving
>>>> PrimitiveClassDescImpl and ConstantDescs, and the result depends on
>>>> which class gets initialized first.
>>>>
>>>> Without my patch this issue is not seen because PrimitiveClassDescImpl
>>>> has already been initialized by the time
>>>> MetaspaceShared::link_shared_classes() is called.
>>>> Its initialization is triggered by the call to
>>>> MethodType::createArchivedObjects().
>>>> It also explains why my patch introduced this issue because it
>>>> effectively moved the call to MethodType::createArchivedObjects()
>>>> after MetaspaceShared::link_shared_classes().
>>>>
>>>> [0]
>>>> https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>>> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>>>
>>>> Thanks,
>>>> - Ashutosh Mehra
>>>>
>>>>
>>>> On Wed, Sep 11, 2024 at 3:12?PM Ashutosh Mehra <asmehra at redhat.com>
>>>> wrote:
>>>>
>>>>> Regarding the WrongMethodTypeException that I mentioned in my previous
>>>>> email (see pt 3),
>>>>> this exception happens when lambda proxy class attempts to invoke the
>>>>> MethodHandle it obtained from the classData:
>>>>>
>>>>>   public void accept(java.lang.Object);
>>>>>     descriptor: (Ljava/lang/Object;)V
>>>>>     flags: (0x0001) ACC_PUBLIC
>>>>>     Code:
>>>>>       stack=3, locals=2, args_size=2
>>>>>          0: ldc           #26                 // Dynamic
>>>>> #0:_:Ljava/lang/invoke/MethodHandle;
>>>>>          2: aload_0
>>>>>          3: getfield      #13                 // Field
>>>>> arg$1:Lorg/wildfly/security/WildFlyElytronBaseProvider;
>>>>>          6: aload_1
>>>>>          7: checkcast     #28                 // class
>>>>> java/security/Provider$Service
>>>>>         10: invokevirtual #34                 // Method
>>>>> java/lang/invoke/MethodHandle.invokeExact:(Lorg/wildfly/security/WildFlyElytronBaseProvider;Ljava/security/Provider$Service;)V
>>>>>         13: return
>>>>>
>>>>> The scenario is during the assembly phase as part of the indy
>>>>> resolution the MethodHandle for which the exception is thrown gets created.
>>>>> Normally MethodHandle's type gets added in MethodType::internTable
>>>>> but by the time indy resolution happens, JVM has already taken
>>>>> snapshot of the MethodType::internTable through an upcall to
>>>>> MethodType::createArchivedObjects().
>>>>> As a result the AOTCache ends up with the MethodType object which is
>>>>> not in AOTHolder.archivedMethodTypes.
>>>>>
>>>>> During the production run, when the jvm invokes the MethodHandle, it
>>>>> searches for the MethodType corresponding to the signature passed at the
>>>>> callsite.
>>>>> As expected, it fails to find it in the AOTHolder.archivedMethodTypes,
>>>>> so it creates a new instance of the MethodType.
>>>>> But Invokers.checkExactType() relies on the MethodHandle's type to be
>>>>> the same object as the MethodType object passed as parameter.
>>>>>
>>>>>     static void checkExactType(MethodHandle mhM, MethodType expected)
>>>>> {
>>>>>         MethodType targetType = mh.type();
>>>>>         if (targetType != expected)
>>>>>             throw newWrongMethodTypeException(targetType, expected);
>>>>>     }
>>>>>
>>>>> Hence, it throws WrongMethodTypeException though the two MT objects
>>>>> have the same signature.
>>>>>
>>>>> To handle this scenario, I changed the order of indy resolution and upcall
>>>>> to MethodType::createArchivedObjects() as:
>>>>>
>>>>> diff --git a/src/hotspot/share/cds/metaspaceShared.cpp
>>>>> b/src/hotspot/share/cds/metaspaceShared.cpp
>>>>> index df4bcadefa3..457716cac5b 100644
>>>>> --- a/src/hotspot/share/cds/metaspaceShared.cpp
>>>>> +++ b/src/hotspot/share/cds/metaspaceShared.cpp
>>>>> @@ -751,6 +751,20 @@ void MetaspaceShared::link_shared_classes(bool
>>>>> jcmd_request, TRAPS) {
>>>>>    if (CDSConfig::is_dumping_final_static_archive()) {
>>>>>      FinalImageRecipes::apply_recipes(CHECK);
>>>>>    }
>>>>> +
>>>>> +#if INCLUDE_CDS_JAVA_HEAP
>>>>> +  if (CDSConfig::is_dumping_invokedynamic()) {
>>>>> +    // This makes sure that the MethodType and MethodTypeForm tables
>>>>> won't be updated
>>>>> +    // concurrently when we are saving their contents into a side
>>>>> table.
>>>>> +    assert(CDSConfig::allow_only_single_java_thread(), "Required");
>>>>> +
>>>>> +    JavaValue result(T_VOID);
>>>>> +    JavaCalls::call_static(&result, vmClasses::MethodType_klass(),
>>>>> +                           vmSymbols::createArchivedObjects(),
>>>>> +                           vmSymbols::void_method_signature(),
>>>>> +                           CHECK);
>>>>> +  }
>>>>> +#endif
>>>>>  }
>>>>>
>>>>> Note that indy resolution happens as part of FinalImageRecipes::apply_recipes(CHECK)
>>>>> which is now invoked before the upcall to createArchivedObjects().
>>>>> With this change I am able to run the application without any
>>>>> exceptions.
>>>>> My complete patch can be seen here:
>>>>> https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>>>> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>>>> I will do more testing with this patch.
>>>>>
>>>>> @Ioi Lam <ioi.lam at oracle.com> do you have any feedback on this patch.
>>>>>
>>>>> Thanks,
>>>>> - Ashutosh Mehra
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Sep 11, 2024 at 10:14?AM Ashutosh Mehra <asmehra at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Andrew,
>>>>>> Thanks for sharing the initial investigation.
>>>>>> I have been looking into this and have a few of things to add to your
>>>>>> analysis:
>>>>>>
>>>>>> 1.  As you mentioned the classData for the lambda
>>>>>> class WildFlyElytronBaseProvider$$Lambda is null.
>>>>>> The classData is stored in the mirror object of the InstanceKlass
>>>>>> when the class is defined through JVM_LookupDefineClass.
>>>>>> However, when we create the scratch mirror object (which get stored
>>>>>> in the AOT cache) the classData is not populated.
>>>>>> See
>>>>>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp#L1128-L1131
>>>>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp*L1128-L1131__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhbKjzG3gw$>
>>>>>>
>>>>>>   Handle classData; // set to null. Will be reinitialized at runtime
>>>>>>   Handle mirror;
>>>>>>   Handle comp_mirror;
>>>>>>   allocate_mirror(k, /*is_scratch=*/true, protection_domain,
>>>>>> classData, mirror, comp_mirror, CHECK);
>>>>>>
>>>>>> So this explains why the call to classData(caller.lookupClass())
>>>>>> returned null.
>>>>>>
>>>>>> 2. In the mainline there is a check
>>>>>> in InnerClassLambdaMetafactory.java for the particular code pattern used by
>>>>>> the application.
>>>>>> If this code pattern is found then the lambda proxy class is not
>>>>>> included in the CDS archive.
>>>>>> See
>>>>>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L163-L170
>>>>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L163-L170__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZl2S9tQg$>
>>>>>> and
>>>>>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L246
>>>>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L246__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhYsI3Xx0g$>
>>>>>>
>>>>>>         // If the target class invokes a protected method inherited
>>>>>> from a
>>>>>>         // superclass in a different package, or does
>>>>>> 'invokespecial', the
>>>>>>         // lambda class has no access to the resolved method, or does
>>>>>>         // 'invokestatic' on a hidden class which cannot be resolved
>>>>>> by name.
>>>>>>         // Instead, we need to pass the live implementation method
>>>>>> handle to
>>>>>>         // the proxy class to invoke directly. (javac prefers to
>>>>>> avoid this
>>>>>>         // situation by generating bridges in the target class)
>>>>>>         useImplMethodHandle =
>>>>>> (Modifier.isProtected(implInfo.getModifiers()) &&
>>>>>>
>>>>>>  !VerifyAccess.isSamePackage(targetClass, implInfo.getDeclaringClass())) ||
>>>>>>                                implKind ==
>>>>>> MethodHandleInfo.REF_invokeSpecial ||
>>>>>>                                implKind ==
>>>>>> MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>>>>>>
>>>>>> In premain lambda proxy classes get included in the AOT cache as a
>>>>>> result of indy resolution and that mechanism doesn't have this kind of
>>>>>> check.
>>>>>>
>>>>>> 3. For the null classData problem mentioned above, I tried to fix it
>>>>>> by storing classData in the scratch mirror using the following patch:
>>>>>>
>>>>>> diff --git a/src/hotspot/share/classfile/javaClasses.cpp
>>>>>> b/src/hotspot/share/classfile/javaClasses.cpp
>>>>>> index bd8141adbcc..41766e98093 100644
>>>>>> --- a/src/hotspot/share/classfile/javaClasses.cpp
>>>>>> +++ b/src/hotspot/share/classfile/javaClasses.cpp
>>>>>> @@ -1094,9 +1094,9 @@ void java_lang_Class::create_mirror(Klass* k,
>>>>>> Handle class_loader,
>>>>>>      }
>>>>>>      if (CDSConfig::is_dumping_heap()) {
>>>>>>        if (CDSConfig::is_dumping_protection_domains()) {
>>>>>> -        create_scratch_mirror(k, protection_domain, CHECK);
>>>>>> +        create_scratch_mirror(k, protection_domain, classData,
>>>>>> CHECK);
>>>>>>        } else {
>>>>>> -        create_scratch_mirror(k, Handle() /* null
>>>>>> protection_domain*/, CHECK);
>>>>>> +        create_scratch_mirror(k, Handle() /* null
>>>>>> protection_domain*/, classData, CHECK);
>>>>>>        }
>>>>>>      }
>>>>>>    } else {
>>>>>> @@ -1117,7 +1117,7 @@ void java_lang_Class::create_mirror(Klass* k,
>>>>>> Handle class_loader,
>>>>>>  // Note: we archive the "scratch mirror" instead of
>>>>>> k->java_mirror(), because the
>>>>>>  // latter may contain dumptime-specific information that cannot be
>>>>>> archived
>>>>>>  // (e.g., ClassLoaderData*, or static fields that are modified by
>>>>>> Java code execution).
>>>>>> -void java_lang_Class::create_scratch_mirror(Klass* k, Handle
>>>>>> protection_domain, TRAPS) {
>>>>>> +void java_lang_Class::create_scratch_mirror(Klass* k, Handle
>>>>>> protection_domain, Handle classData, TRAPS) {
>>>>>>    if (k->class_loader() != nullptr &&
>>>>>>        k->class_loader() != SystemDictionary::java_platform_loader()
>>>>>> &&
>>>>>>        k->class_loader() != SystemDictionary::java_system_loader()) {
>>>>>> @@ -1125,9 +1125,11 @@ void
>>>>>> java_lang_Class::create_scratch_mirror(Klass* k, Handle protection_domain,
>>>>>>      return;
>>>>>>    }
>>>>>>
>>>>>> -  Handle classData; // set to null. Will be reinitialized at runtime
>>>>>> +  //Handle classData; // set to null. Will be reinitialized at
>>>>>> runtime
>>>>>>    Handle mirror;
>>>>>>    Handle comp_mirror;
>>>>>>    allocate_mirror(k, /*is_scratch=*/true, protection_domain,
>>>>>> classData, mirror, comp_mirror, CHECK);
>>>>>>
>>>>>>    if (comp_mirror() != nullptr) {
>>>>>> diff --git a/src/hotspot/share/classfile/javaClasses.hpp
>>>>>> b/src/hotspot/share/classfile/javaClasses.hpp
>>>>>> index bc49a0861a7..7ec2a2556dd 100644
>>>>>> --- a/src/hotspot/share/classfile/javaClasses.hpp
>>>>>> +++ b/src/hotspot/share/classfile/javaClasses.hpp
>>>>>> @@ -263,7 +263,7 @@ class java_lang_Class : AllStatic {
>>>>>>
>>>>>>    // Archiving
>>>>>>    static void serialize_offsets(SerializeClosure* f) NOT_CDS_RETURN;
>>>>>> -  static void create_scratch_mirror(Klass* k, Handle
>>>>>> protection_domain, TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>>>>>> +  static void create_scratch_mirror(Klass* k, Handle
>>>>>> protection_domain, Handle classData, TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>>>>>>    static bool restore_archived_mirror(Klass *k, Handle class_loader,
>>>>>> Handle module,
>>>>>>                                        Handle protection_domain,
>>>>>>                                        TRAPS)
>>>>>> NOT_CDS_JAVA_HEAP_RETURN_(false);
>>>>>>
>>>>>> But this resulted in a different exception:
>>>>>>
>>>>>> Exception in thread "main" java.lang.ExceptionInInitializerError
>>>>>> at com.redhat.leyden.Main.main(Main.java:7)
>>>>>> Caused by: java.lang.invoke.WrongMethodTypeException: handle's method
>>>>>> type (WildFlyElytronBaseProvider,Service)void but found
>>>>>> (WildFlyElytronBaseProvider,Service)void
>>>>>> at
>>>>>> java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>>>>>> at
>>>>>> java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>>>>>> at
>>>>>> java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
>>>>>> at
>>>>>> org.wildfly.security.WildFlyElytronBaseProvider$$Lambda/0x80000000c.accept(Unknown
>>>>>> Source)
>>>>>> at
>>>>>> org.wildfly.security.WildFlyElytronBaseProvider.putMakedPasswordImplementations(WildFlyElytronBaseProvider.java:112)
>>>>>> at
>>>>>> org.wildfly.security.WildFlyElytronBaseProvider.putPasswordImplementations(WildFlyElytronBaseProvider.java:107)
>>>>>> at
>>>>>> org.wildfly.security.password.WildFlyElytronPasswordProvider.<init>(WildFlyElytronPasswordProvider.java:43)
>>>>>> at
>>>>>> org.wildfly.security.password.WildFlyElytronPasswordProvider.<clinit>(WildFlyElytronPasswordProvider.java:36)
>>>>>> ... 1 more
>>>>>>
>>>>>> The exception message is strange because the handle's method type and
>>>>>> the expected type are both symbolically the same.
>>>>>> I am debugging this exception at the moment.
>>>>>>
>>>>>> Thanks,
>>>>>> - Ashutosh Mehra
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 11, 2024 at 6:03?AM Andrew Dinn <adinn at redhat.com> wrote:
>>>>>>
>>>>>>> Oops, sorry, I debugged this a few days ago! Correction to a few
>>>>>>> details:
>>>>>>>
>>>>>>> On 11/09/2024 10:39, Andrew Dinn wrote:
>>>>>>> > A crash due to an NPE was observed in the Infinispan (Data Grid)
>>>>>>> server
>>>>>>> > app when deployed using the Leyden EA. The crash still manifests
>>>>>>> with
>>>>>>> > the latest premain code. The crash happens below an application
>>>>>>> call
>>>>>>> > which employs a method reference as argument
>>>>>>> >
>>>>>>> >          putMakedPasswordImplementations(this::putService, this);
>>>>>>>
>>>>>>> The called method in turn calls consumer.accept
>>>>>>>
>>>>>>>              consumer.accept(new Service(provider,
>>>>>>> PASSWORD_FACTORY_TYPE, algorithm,
>>>>>>> "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>>>>>> emptyList,
>>>>>>> emptyMap));
>>>>>>>
>>>>>>> which enters enters MethodHandleNative::linkDynamicConstant()
>>>>>>>
>>>>>>> > Debugging shows that the call to linkDynamicConstant() returns
>>>>>>> null.
>>>>>>> >
>>>>>>> > A simple reproducer for the problem is available as a maven
>>>>>>> project on
>>>>>>> > github:
>>>>>>> >
>>>>>>> >    https://github.com/tristantarrant/elytron-leyden
>>>>>>> <https://urldefense.com/v3/__https://github.com/tristantarrant/elytron-leyden__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZaZr1akQ$>
>>>>>>> >
>>>>>>> > The ReadMe provides an explanation of how to reproduce the
>>>>>>> problem. I
>>>>>>> > did so and the debugged to find out some of the details of what is
>>>>>>> > happening (see below) but did not fully clarify the problem. Help
>>>>>>> from
>>>>>>> > someone more conversant with the ins and outs of method handle
>>>>>>> > bootstraps in premain would be welcome. Details follow.
>>>>>>> >
>>>>>>> > regards,
>>>>>>> >
>>>>>>> >
>>>>>>> > Andrew Dinn
>>>>>>> > -----------
>>>>>>> >
>>>>>>> > I downloaded the git repo and attached the Java sources using
>>>>>>> Maven command
>>>>>>> >
>>>>>>> >    $ mvn dependency:sources
>>>>>>> >
>>>>>>> > Having manifested the crash by following the instructions in the
>>>>>>> README
>>>>>>> > I reran the leyden JVM under gdb using the following commands to
>>>>>>> enable
>>>>>>> > Java debugging
>>>>>>> >
>>>>>>> > $ gdb ${LEYDEN_HOME}/bin/java
>>>>>>> > (gdb) cd /path/to/mvn/project
>>>>>>> > (gdb) run
>>>>>>> > -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
>>>>>>> > -classpath
>>>>>>> >
>>>>>>> /home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/
>>>>>>> 2.5.1.
>>>>>>> <https://urldefense.com/v3/__http://2.5.1.__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhauJ-RjcQ$>Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar
>>>>>>> -XX:CacheDataStore=elytron.aot com.redhat.leyden.Main
>>>>>>> >
>>>>>>> > The problem manifests at WildflyElytronBaseProvider.java:112 in
>>>>>>> method
>>>>>>> > WildflyElytronBaseProvider::putMakedPasswordImplementations
>>>>>>>
>>>>>>>      static void putMakedPasswordImplementations(Consumer<Service>
>>>>>>> consumer, Provider provider) {
>>>>>>>          for (String algorithm : MASKED_ALGORITHMS) {
>>>>>>>              consumer.accept(new Service(provider,
>>>>>>> PASSWORD_FACTORY_TYPE, algorithm,
>>>>>>> "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>>>>>> emptyList,
>>>>>>> emptyMap)); <== NPE under this call
>>>>>>>          }
>>>>>>>
>>>>>>>
>>>>>>> > The source code for this method can be found in the following
>>>>>>> source jar
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> ${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar
>>>>>>> >
>>>>>>> > (where M2_REPO will normally be ~/.m2/repository)
>>>>>>> >
>>>>>>> > Stepping into accept eventually enters
>>>>>>> MethodHandleNative::linkDynamicConstant
>>>>>>> > which in turn enters into ConstantBootstraps.makeConstant(). The
>>>>>>> caller
>>>>>>> > Class at this point is a lambda class which prints as
>>>>>>> >
>>>>>>> org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c
>>>>>>> >
>>>>>>> > Several steps further the code enters
>>>>>>> BootstrapMethodInvoker::invoke
>>>>>>> > (below the app method call but via 3 hidden frames) with
>>>>>>> bootstrapMethod
>>>>>>> > bound to a DirectMethodHandle. After several more steps this
>>>>>>> enters
>>>>>>> > DirectMethodHandle$Holder.invokeStatic which in turn calls
>>>>>>> > MethodHandles::classData(Lookup,String,Class).
>>>>>>> >
>>>>>>> > At this point caller is a MethodHandleLookup for the lambda class
>>>>>>> > Lambda/0x800000000c mentioned above. The following call
>>>>>>> >
>>>>>>> >           Object classdata = classData(caller.lookupClass());
>>>>>>> >
>>>>>>> > returns null to DirectMethodHandle$Holder.invokeStatic which pops
>>>>>>> the
>>>>>>> > same result back out to BootstrapMethodInvoker::invoke at line 90
>>>>>>> >
>>>>>>> >                  if (type instanceof Class<?> c) {
>>>>>>> >                      result = bootstrapMethod.invoke(caller, name,
>>>>>>> c);
>>>>>>> > <== null
>>>>>>> >
>>>>>>> > This null result pops back out as the value for the call to
>>>>>>> > BootstrapMethodInvoker.invoke(), ConstantBootstraps.makeConstant()
>>>>>>> and
>>>>>>> > MethodHandleNative::linkDynamicConstant().
>>>>>>> >
>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240924/8f715dc0/attachment.htm>

From duke at openjdk.org  Tue Sep 24 16:57:31 2024
From: duke at openjdk.org (duke)
Date: Tue, 24 Sep 2024 16:57:31 GMT
Subject: git: openjdk/leyden: created branch fix-elytron-leyden based on the
 branch premain containing 2 unique commits
Message-ID: <79d2226d-ac67-4043-9ec0-691d71e99058@openjdk.org>

The following commits are unique to the fix-elytron-leyden branch:
========================================================
eafaa973: Fixes for bug reported by https://github.com/tristantarrant/elytron-leyden
df72d0ba: disable AOTClassInitializer::is_forced_preinit_class()

From ioi.lam at oracle.com  Tue Sep 24 17:01:09 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Tue, 24 Sep 2024 10:01:09 -0700
Subject: [External] : Re: premain: Crash in Infinispan server code caused
 by NPE under MethodHandleNative::linkDynamicConstant
In-Reply-To: <CAKt0pyTQXoW82Dx=BRFx93_wm6dEiCcncT66mDOHGXt4GqiE0Q@mail.gmail.com>
References: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
 <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>
 <CAKt0pySztvwsadtrqjai6XwakAWq_v_o8men4aopLo4X-0azyQ@mail.gmail.com>
 <CAKt0pyQ44E+npyUW35Zhxg+PfBgF2yuNgS61gj1GGj=aLGTJXw@mail.gmail.com>
 <CAKt0pyT48uPH6rUL7bEJ2rtWqNdNL34DWBJ2SDaHwYfVxURnQw@mail.gmail.com>
 <0d22d580-39a1-4105-a50e-8a74a555090d@oracle.com>
 <CAKt0pyRYBNtkLzVoAfDHWE=4e+9efZFb+xKYZv-d3LpDAU4qZg@mail.gmail.com>
 <da797fe2-137c-4fc7-a67c-3b595c0c63f2@oracle.com>
 <CAKt0pyRj8_mDiH58v10sqXNHA4iHja6-7D9N_S2VW9rhESPcTw@mail.gmail.com>
 <45e62b78-bbde-4ba5-8b20-77125d14b908@oracle.com>
 <4dc70b95-f014-44f1-acfb-027c8e28e81d@oracle.com>
 <CAKt0pyQ8T+-yZQ1UJBewcc_DXTMRymNRSp3cz4xCZf54XUhw+g@mail.gmail.com>
 <9ec705a7-4fa5-40f8-8685-b49c54ab4418@oracle.com>
 <CAKt0pyTQXoW82Dx=BRFx93_wm6dEiCcncT66mDOHGXt4GqiE0Q@mail.gmail.com>
Message-ID: <199d99cb-5e4c-40c6-a9b5-3e5e456f1968@oracle.com>

Hi Ashutosh,

I disabled the AOTClassInitializer::is_forced_preinit_class() call and 
synced AOTClassInitializer::can_archive_preinitialized_mirror() with my 
upstream PR. This seems to fix the error in your test case.

Could you give it a try?

https://github.com/iklam/jdk/commit/df72d0ba8dc799767521c939a531c4128e58c636

Thanks

- Ioi


https://github.com/iklam/jdk/commit/df72d0ba8dc799767521c939a531c4128e58c636

On 9/24/24 8:24 AM, Ashutosh Mehra wrote:
> Hi Ioi,
> Thanks for sharing the code changes.
> The wildfly-elytron testcase passes with these changes, but I still 
> get the NPE in?PrimitiveClassDescImpl.<clinit> when running with my 
> own testcase.
> I have pushed my test case to a repo [2], so you can try it as well. I 
> have added some instructions to the Readme file.
> Let me know if you face any issues in running the test case.
>
> [2] https://github.com/ashu-mehra/leyden-testcase/ 
> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden-testcase/__;!!ACWV5N9M2RV99hQ!JiRlHQ7c-vdXVJoc61a64CilNOg5VTLitO8JELhohSZdibAXZUEjeA38WbtygjLvPsQIQKUYXJ2_kA$>
>
> Thanks,
> - Ashutosh Mehra
>
>
> On Mon, Sep 23, 2024 at 11:24?PM <ioi.lam at oracle.com> wrote:
>
>     Hi Ashutosh,
>
>     Thank you again for the summary of the issues.
>
>     I looked at the call paths again and I think two calls need to be
>     moved
>
>         (1) MethodType::createArchivedObjects() needs to be called
>         after we have executed all other Java code. So I put it before
>         the StringTable::allocate_shared_strings_array() call.
>
>         (2) SystemDictionary::get_all_method_handle_intrinsics() needs
>         to be done inside the safepoint, so it can be sure to find all
>         the method handle intrinsic methods (which can be generated as
>         the side effect of Java code execution).
>
>         I also added the archiving of the classData field.
>
>     See my temporary change at
>     https://github.com/iklam/jdk/commit/eafaa9731ae89b93f3e20702fc4d5a12cb070149
>     <https://urldefense.com/v3/__https://github.com/iklam/jdk/commit/eafaa9731ae89b93f3e20702fc4d5a12cb070149__;!!ACWV5N9M2RV99hQ!JiRlHQ7c-vdXVJoc61a64CilNOg5VTLitO8JELhohSZdibAXZUEjeA38WbtygjLvPsQIQKXvE8zr1g$>
>
>     With this change, I am able to successfully run the test in
>     https://github.com/tristantarrant/elytron-leyden
>     <https://urldefense.com/v3/__https://github.com/tristantarrant/elytron-leyden__;!!ACWV5N9M2RV99hQ!JiRlHQ7c-vdXVJoc61a64CilNOg5VTLitO8JELhohSZdibAXZUEjeA38WbtygjLvPsQIQKW7YFmGjQ$>
>     . I also modified the LambdaWithUseImplMethodHandle.java test to
>     add a similar test scenario.
>
>     I agree with you that the code in
>     AOTClassInitializer::is_forced_preinit_class() is too ad-hoc, and
>     might change the order of class initialization. In the upstream
>     PR, I have changed the code to only assert that the listed of
>     classes has been initialized:
>
>     https://github.com/iklam/jdk/blob/5cc31ed60cc9597d63b86f20b95c964d4d1a6b84/src/hotspot/share/cds/aotClassInitializer.cpp#L66-L84
>     <https://urldefense.com/v3/__https://github.com/iklam/jdk/blob/5cc31ed60cc9597d63b86f20b95c964d4d1a6b84/src/hotspot/share/cds/aotClassInitializer.cpp*L66-L84__;Iw!!ACWV5N9M2RV99hQ!JiRlHQ7c-vdXVJoc61a64CilNOg5VTLitO8JELhohSZdibAXZUEjeA38WbtygjLvPsQIQKUJSR9oEw$>
>
>     I will try to merge this version of the code back to the Leyden repo.
>
>     I think by doing this, we can avoid direct manipulation of the
>     class-init order of the core-library classes. Instead, we just
>     make sure that we execute enough "normal" code during the assembly
>     phase to ensure that these classes are initialized in their normal
>     order.
>
>     What do you think?
>
>     Thanks
>
>     - Ioi
>
>
>     On 9/19/24 8:05 PM, Ashutosh Mehra wrote:
>>
>>         Upon further investigation, it seems a simple patch might fix
>>         the problem with classData.
>>
>>         I tested with
>>         test/hotspot/jtreg/runtime/cds/appcds/LambdaWithUseImplMethodHandle.java
>>         by running jtreg with -javaoptions:-XX:+AOTClassLinking
>>         Without the patch, I'd get a NullPointerException. With the
>>         patch, the test passes.
>>
>>         It looks like classData is not treated as a static field of
>>         the class, but rather an instance field in the mirror. So
>>         classData wasn't copied by the loop in
>>         HeapShared::copy_preinitialized_mirror().
>>
>>         Ashutosh, could you try it this fixes the crash on your side?
>>
>>         Thanks
>>
>>         - Ioi
>>
>>         diff --git a/src/hotspot/share/cds/heapShared.cpp
>>         b/src/hotspot/share/cds/heapShared.cpp
>>         index 0e70778f057..62cf142f67a 100644
>>         --- a/src/hotspot/share/cds/heapShared.cpp
>>         +++ b/src/hotspot/share/cds/heapShared.cpp
>>         @@ -634,6 +634,8 @@ void
>>         HeapShared::copy_preinitialized_mirror(Klass* orig_k, oop
>>         orig_mirror, oop
>>         ???? }
>>         ?? }
>>
>>         +? java_lang_Class::set_class_data(m,
>>         java_lang_Class::class_data(orig_mirror));
>>         +
>>         ?? // Class::reflectData use SoftReference, which cannot be
>>         archived. Set it
>>         ?? // to null and it will be recreated at runtime.
>>         ?? java_lang_Class::set_reflection_data(m, nullptr);
>>
>>
>>     Hi Ioi,
>>
>>     This patch effectively does the same thing as my initial patch
>>     for storing classData in the scratch mirror object [1].
>>
>>     At this point I think it would be useful to do a quick recap of
>>     the issues mentioned in this thread. There are 3 issues I have
>>     encountered so far.
>>     I was initially thinking of a solution that would cover all these
>>     problems, but looking at these again, I feel these are orthogonal
>>     to each other:
>>
>>     1. The missing classData in scratch mirrors which can be fixed by
>>     either of the patches shared in this thread. They achieve the
>>     same goal and I don't have any strong preference for any of them.
>>
>>     2. After fixing the classData, I ran into
>>     WrongMethodTypeException issue [2] which I fixed by exchanging
>>     the order of indy resolution with the call to
>>     MethodType::createArchivedObjects [3].
>>     This change makes sense because we want to make sure all the
>>     MethodType objects that can be archived are in
>>     MethodType?internTable before calling
>>     MethodType::createArchivedObjects.
>>     I am not sure why LambdaWithUseImplMethodHandle.java didn't throw
>>     the WrongMethodTypeException, as the Infinispan code does.
>>
>>     3. After fixing the WrongMethodTypeException I hit NPE due to the
>>     class initialization cycle between PrimitiveClassDescImpl?and
>>     ConstantDescs [4] in one of my own testcase.
>>     We are looking for a solution to this problem. I am not sure if
>>     we can break this cycle by?refactoring the?Java code.
>>     Nevertheless, I think it is fair to assume that there is no Java
>>     code that can initiate initialization of PrimitiveClassDescImpl
>>     beforeConstantDescs, otherwise we would have hit the NPE earlier.
>>     So if ConstantDescsis always expected to be initialized before
>>     PrimitiveClassDescImpl?then I think the VM code should also
>>     maintain this assumption.
>>     Now this brings us back to the forceful initialization done by
>>     the VM during the assembly phase based on the
>>     forced_preinit_classes list in aotClassInitializer.cpp:
>>
>>     ? ? // TODO:
>>     ? ? // This is needed since JDK-8338532. Without this, when
>>     ? ? // archived heap objects are used, the class init order is not
>>     ? ? // expected by the jdk/internal/constant bootstrap code and we
>>     ? ? // will get a null pointer exception.
>>     ? ? //
>>     ? ? // When bootstraping has intricated/fragile order, it's probably
>>     ? ? // better to archive all related classes in an initialized state
>>     ? ? // (i.e., take a snapshot). The existing approach in
>>     ? ? // heapShared::resolve_or_init_classes_for_subgraph_of()
>>     won't work.
>>     ? ? "jdk/internal/constant/PrimitiveClassDescImpl",
>>     ? ? "jdk/internal/constant/ReferenceClassDescImpl",
>>     ? ? "java/lang/constant/ConstantDescs",
>>     ? ? "sun/invoke/util/Wrapper",
>>
>>     I wonder why we need to explicitly add PrimitiveClassDescImpl?and
>>     ReferenceClassDescImpl?in this list.
>>     Initialization of ConstantDescs?would anyway trigger the
>>     initialization of PrimitiveClassDescImpl?and ReferenceClassDescImpl.
>>     So if we only keep the entry for ConstantDescs?and remove
>>     PrimitiveClassDescImpl?and ReferenceClassDescImpl?from this list,
>>     we can be sure that the forceful initialization by the VM would
>>     maintain the same order of initialization as guided by the Java code,
>>     and we will not hit the NPE when initializing
>>     PrimitiveClassDescImpl during the assembly phase.
>>     Does this make sense?
>>
>>
>>     [1]
>>     https://mail.openjdk.org/pipermail/leyden-dev/2024-September/000994.html
>>     [2]
>>     https://mail.openjdk.org/pipermail/leyden-dev/2024-September/000997.html
>>     [3]
>>     https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>     <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!KvYLs_vG0a4GO3ltinXQkxBG1kMhCAvmmM6MwODoKzOhhVjzNL80S_0mBzYvYyhYPQnGmXhAXSw78Q$>
>>     [4]
>>     https://mail.openjdk.org/pipermail/leyden-dev/2024-September/001018.html
>>
>>     Thanks,
>>     - Ashutosh Mehra
>>
>>
>>     On Thu, Sep 19, 2024 at 8:51?PM <ioi.lam at oracle.com> wrote:
>>
>>         Upon further investigation, it seems a simple patch might fix
>>         the problem with classData.
>>
>>         I tested with
>>         test/hotspot/jtreg/runtime/cds/appcds/LambdaWithUseImplMethodHandle.java
>>         by running jtreg with -javaoptions:-XX:+AOTClassLinking
>>         Without the patch, I'd get a NullPointerException. With the
>>         patch, the test passes.
>>
>>         It looks like classData is not treated as a static field of
>>         the class, but rather an instance field in the mirror. So
>>         classData wasn't copied by the loop in
>>         HeapShared::copy_preinitialized_mirror().
>>
>>         Ashutosh, could you try it this fixes the crash on your side?
>>
>>         Thanks
>>
>>         - Ioi
>>
>>         diff --git a/src/hotspot/share/cds/heapShared.cpp
>>         b/src/hotspot/share/cds/heapShared.cpp
>>         index 0e70778f057..62cf142f67a 100644
>>         --- a/src/hotspot/share/cds/heapShared.cpp
>>         +++ b/src/hotspot/share/cds/heapShared.cpp
>>         @@ -634,6 +634,8 @@ void
>>         HeapShared::copy_preinitialized_mirror(Klass* orig_k, oop
>>         orig_mirror, oop
>>         ???? }
>>         ?? }
>>
>>         +? java_lang_Class::set_class_data(m,
>>         java_lang_Class::class_data(orig_mirror));
>>         +
>>         ?? // Class::reflectData use SoftReference, which cannot be
>>         archived. Set it
>>         ?? // to null and it will be recreated at runtime.
>>         ?? java_lang_Class::set_reflection_data(m, nullptr);
>>
>>
>>
>>         On 9/19/24 12:51 PM, ioi.lam at oracle.com wrote:
>>>
>>>
>>>         On 9/19/24 7:44 AM, Ashutosh Mehra wrote:
>>>>
>>>>             As I am cleaning up the code for upstreaming to
>>>>             mainline, I am going add an equivalent check in the C
>>>>             code to filter out these indy call sites, so they won't
>>>>             be resolved at all during the assembly phase.
>>>>             Otherwise, I will run into problems described in
>>>>             https://bugs.openjdk.org/browse/JDK-8290417
>>>>
>>>>
>>>>         Thanks for the link to the bug. The scenario described in
>>>>         that bug is exactly the same as the Infinispan case.
>>>>         So if we filter out such cases during indy resolution then
>>>>         it should resolve the Infinispan issue as well.
>>>>
>>>>         A basic question: why?can't CDS handle the lambda proxy
>>>>         class generated in useImplMethodHandle?mode?
>>>>
>>>         If I remember correctly, it has to do with the shape of
>>>         dynamically generated bytecode:
>>>
>>>         ? public void accept(java.lang.Object);
>>>         ??? Code:
>>>         ?????? 0: ldc #28 // Dynamic
>>>         #0:_:Ljava/lang/invoke/MethodHandle;
>>>         ?????? 2: aload_0
>>>         ?????? 3: getfield #15 // Field arg$1:LTester;
>>>         ?????? 6: aload_1
>>>         ?????? 7: checkcast #30 // class java/lang/String
>>>         ????? 10: invokevirtual #36 // Method
>>>         java/lang/invoke/MethodHandle.invokeExact:(LTester;Ljava/lang/String;)V
>>>         ????? 13: return
>>>
>>>         The result of the "ldc" was not symbolically encoded in the
>>>         generated class (as the generated class has no permission to
>>>         access that method). So the MethodHandle is stored as a
>>>         binary object in the mirror of this generated class (with
>>>         the java.lang.Class::classData field).
>>>
>>>         Plain CDS doesn't archive class mirrors, so the classData
>>>         will be lost.
>>>
>>>         With JEP 483, we should be able to preserve the classData,
>>>         so I am not sure why the useImplMethodHandle case is still
>>>         failing. My plan is to filter these out for now, but I will
>>>         get back to it later when I have more time.
>>>
>>>         Thanks
>>>
>>>         - Ioi
>>>
>>>
>>>
>>>
>>>>         Thanks,
>>>>         - Ashutosh Mehra
>>>>
>>>>
>>>>         On Thu, Sep 19, 2024 at 1:45?AM <ioi.lam at oracle.com> wrote:
>>>>
>>>>             Hi Ashutosh,
>>>>
>>>>             I have some update:
>>>>
>>>>             The original crash was caused by the
>>>>             "useImplMethodHandle" code in
>>>>             InnerClassLambdaMetafactory.java:
>>>>
>>>>             ??????? // If the target class invokes a protected
>>>>             method inherited from a
>>>>             ??????? // superclass in a different package, or does
>>>>             'invokespecial', the
>>>>             ??????? // lambda class has no access to the resolved
>>>>             method, or does
>>>>             ??????? // 'invokestatic' on a hidden class which
>>>>             cannot be resolved by name.
>>>>             ??????? // Instead, we need to pass the live
>>>>             implementation method handle to
>>>>             ??????? // the proxy class to invoke directly. (javac
>>>>             prefers to avoid this
>>>>             ??????? // situation by generating bridges in the
>>>>             target class)
>>>>             ??????? useImplMethodHandle =
>>>>             (Modifier.isProtected(implInfo.getModifiers()) &&
>>>>             !VerifyAccess.isSamePackage(targetClass,
>>>>             implInfo.getDeclaringClass())) ||
>>>>             ?????????????????????????????? implKind ==
>>>>             MethodHandleInfo.REF_invokeSpecial ||
>>>>             ?????????????????????????????? implKind ==
>>>>             MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>>>>
>>>>             As I am cleaning up the code for upstreaming to
>>>>             mainline, I am going add an equivalent check in the C
>>>>             code to filter out these indy call sites, so they won't
>>>>             be resolved at all during the assembly phase.
>>>>             Otherwise, I will run into problems described in
>>>>             https://bugs.openjdk.org/browse/JDK-8290417
>>>>
>>>>             Once I get the filtering code working, I will integrate
>>>>             it back to premain.
>>>>
>>>>             >I am wondering if we can workaround class circularity
>>>>             issues by recording class initialization order
>>>>             >during training run and use that to guide the
>>>>             initialization during assembly phase.
>>>>
>>>>             In the production run we take different paths than the
>>>>             training run
>>>>
>>>>             (1) some classes are aot-initialized (especially the enums)
>>>>             (2) some classes make special CDS calls
>>>>
>>>>             so I am not sure if it's possible to get the same
>>>>             initialization order as in the training run (or
>>>>             assembly phase).
>>>>
>>>>             (more below)
>>>>
>>>>             On 9/18/24 9:10 AM, Ashutosh Mehra wrote:
>>>>>             Hi Ioi,
>>>>>
>>>>>                 I was having a similar circularity issue (but in
>>>>>                 production time) and I just added enough classes
>>>>>                 to make the NPE go away.
>>>>>
>>>>>             I am wondering if you have a test case that reproduces
>>>>>             the NPE which prompted you to add these classes:
>>>>>
>>>>>             https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp#L65-L78
>>>>>             <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp*L65-L78__;Iw!!ACWV5N9M2RV99hQ!NYvqLbb_Ib2kSdm2fcYVLGby-AiB2TG7KtC1HQHVKLiM-_kRb5mOt8krV5IZfReaYZ0MPadDfa08hQ$>
>>>>>
>>>>>             I commented this code and ran the tests under premain
>>>>>             but didn't hit?the NPE.
>>>>>
>>>>             I forgot what the problem was, but it happened for very
>>>>             simple cases.
>>>>
>>>>             Thanks
>>>>
>>>>             - Ioi
>>>>
>>>>
>>>>>             Thanks,
>>>>>             - Ashutosh Mehra
>>>>>
>>>>>
>>>>>             On Tue, Sep 17, 2024 at 1:11?AM <ioi.lam at oracle.com>
>>>>>             wrote:
>>>>>
>>>>>                 Hi Ashutosh,
>>>>>
>>>>>                 So this looks like a potential bug (or feature) in
>>>>>                 the core lib code. When CDS forcefully initializes
>>>>>                 a class in an unexpected (or untested) order, the
>>>>>                 "initialization soup" fails.
>>>>>
>>>>>                 Perhaps a work-around would be to make some
>>>>>                 harmless calls at the place where CDS was calling
>>>>>                 into MethodType.createArchivedObjects(). E.g., do
>>>>>                 something like this:
>>>>>
>>>>>                 +??? if (CDSConfig::is_dumping_invokedynamic()) {
>>>>>                 +?????? // call into Java:
>>>>>                 jdk.internal.misc::warmupInvokeDynamic();
>>>>>                 +?? }
>>>>>                 ??? // Rewrite and link classes
>>>>>                 ??? log_info(cds)("Rewriting and linking classes
>>>>>                 ...");
>>>>>
>>>>>                 Maybe you can add a new Lambda expressions,
>>>>>                 MethodHandle invocations, etc, that would
>>>>>                 hopefully cause PrimitiveClassDescImpl and friends
>>>>>                 to be initialized in their natural order.
>>>>>
>>>>>                 Or call
>>>>>                 class.forName("java.lang.constant.ConstantDescs") ??
>>>>>
>>>>>                 BTW, you can see my comments in
>>>>>                 AOTClassInitializer::is_forced_preinit_class():
>>>>>
>>>>>                 ??? // TODO:
>>>>>                 ??? // This is needed since JDK-8338532. Without
>>>>>                 this, when
>>>>>                 ??? // archived heap objects are used, the class
>>>>>                 init order is not
>>>>>                 ??? // expected by the jdk/internal/constant
>>>>>                 bootstrap code and we
>>>>>                 ??? // will get a null pointer exception.
>>>>>                 ??? //
>>>>>                 ??? // When bootstraping has intricated/fragile
>>>>>                 order, it's probably
>>>>>                 ??? // better to archive all related classes in an
>>>>>                 initialized state
>>>>>                 ??? // (i.e., take a snapshot). The existing
>>>>>                 approach in
>>>>>                 ??? //
>>>>>                 heapShared::resolve_or_init_classes_for_subgraph_of()
>>>>>                 won't work.
>>>>>                 "jdk/internal/constant/PrimitiveClassDescImpl",
>>>>>                 "jdk/internal/constant/ReferenceClassDescImpl",
>>>>>                 "java/lang/constant/ConstantDescs",
>>>>>                 ??? "sun/invoke/util/Wrapper",
>>>>>
>>>>>                 I was having a similar circularity issue (but in
>>>>>                 production time) and I just added enough classes
>>>>>                 to make the NPE go away. For your test case, if
>>>>>                 you manage to fix in in the assembly run but run
>>>>>                 into NPE in production run, you might need to add
>>>>>                 more classes to this list. Yes, it's a hack :-(
>>>>>
>>>>>
>>>>>                 Thanks
>>>>>
>>>>>                 - Ioi
>>>>>
>>>>>                 On 9/13/24 7:05 PM, Ashutosh Mehra wrote:
>>>>>>                 This is turning out to be a real example of class
>>>>>>                 initialization soup!
>>>>>>                 As mentioned during the meeting, I am getting NPE
>>>>>>                 in the assembly phase when testing the patch [0]
>>>>>>                 that I proposed in my earlier mail
>>>>>>                 using a test case inspired by the Infinispan code.
>>>>>>                 NPE occurs when running the class initializer for
>>>>>>                 PrimitiveClassDescImpl
>>>>>>                 Interestingly, PrimitiveClassDescImpl?is
>>>>>>                 "forcefully" initialized by
>>>>>>                 MetaspaceShared::link_shared_classes().
>>>>>>
>>>>>>                 I couldn't get a stack trace so I relied on
>>>>>>                 exception logs (using -Xlog:exceptions=trace) to
>>>>>>                 find the cause which indicate following frames on
>>>>>>                 the stack:
>>>>>>
>>>>>>                 [0]
>>>>>>                 jdk/internal/constant/MethodTypeDescImpl::validateArgument(Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/ClassDesc;?@
>>>>>>                 bci 1
>>>>>>                 [1]
>>>>>>                 jdk/internal/constant/MethodTypeDescImpl::ofTrusted(Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljdk/internal/constant/MethodTypeDescImpl;?@
>>>>>>                 bci 27
>>>>>>                 [2]
>>>>>>                 java/lang/constant/ConstantDescs::ofConstantBootstrap(Ljava/lang/constant/ClassDesc;Ljava/lang/String;Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/DirectMethodHandleDesc;?@
>>>>>>                 bci 47
>>>>>>                 [3] java/lang/constant/ConstantDescs::<clinit>?@
>>>>>>                 bci 664
>>>>>>                 [4]
>>>>>>                 jdk/internal/constant/PrimitiveClassDescImpl::<init>(Ljava/lang/String;)V?@
>>>>>>                 bci 1
>>>>>>                 [5]
>>>>>>                 jdk/internal/constant/PrimitiveClassDescImpl::<clinit>(Ljava/lang/String;)V?@
>>>>>>                 bci 6
>>>>>>
>>>>>>                 Notice?that invocation of
>>>>>>                 PrimitiveClassDescImpl::<clinit> results in
>>>>>>                 initialization of ConstantDescs?class (see frame 3).
>>>>>>                 ConstantDescs::<clinit>?@ 664 corresponds to
>>>>>>                 following java code:
>>>>>>
>>>>>>                 ? public static final DirectMethodHandleDesc
>>>>>>                 BSM_CLASS_DATA_AT
>>>>>>                 ? ? ? ? ? = ofConstantBootstrap(CD_MethodHandles,
>>>>>>                 "classDataAt",
>>>>>>                 CD_Object, CD_int);
>>>>>>
>>>>>>                 The last parameter CD_int is initialized as:
>>>>>>
>>>>>>                 ? public static final ClassDesc CD_int =
>>>>>>                 PrimitiveClassDescImpl.CD_int;
>>>>>>
>>>>>>                 So, its value is obtained from
>>>>>>                 PrimitiveClassDescImpl.CD_int?which hasn't been
>>>>>>                 initialized properly yet. As a result
>>>>>>                 ConstantDescs::CD_int is assigned?null which
>>>>>>                 results in MethodTypeDescImpl::validateArgument
>>>>>>                 throwing NPE later.
>>>>>>                 There is a clear class initialization circularity
>>>>>>                 involving PrimitiveClassDescImpl and
>>>>>>                 ConstantDescs, and the result depends on which
>>>>>>                 class gets initialized first.
>>>>>>
>>>>>>                 Without my patch this issue is not seen because
>>>>>>                 PrimitiveClassDescImpl has already been
>>>>>>                 initialized by the time
>>>>>>                 MetaspaceShared::link_shared_classes()?is called.
>>>>>>                 Its initialization is triggered by the call to
>>>>>>                 MethodType::createArchivedObjects().
>>>>>>                 It also explains why my patch introduced this
>>>>>>                 issue because it effectively moved the call to
>>>>>>                 MethodType::createArchivedObjects() after
>>>>>>                 MetaspaceShared::link_shared_classes().
>>>>>>
>>>>>>                 [0]
>>>>>>                 https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>>>>>                 <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>>>>>
>>>>>>                 Thanks,
>>>>>>                 - Ashutosh Mehra
>>>>>>
>>>>>>
>>>>>>                 On Wed, Sep 11, 2024 at 3:12?PM Ashutosh Mehra
>>>>>>                 <asmehra at redhat.com> wrote:
>>>>>>
>>>>>>                     Regarding the WrongMethodTypeException that I
>>>>>>                     mentioned in my previous email (see pt 3),
>>>>>>                     this exception happens when lambda proxy
>>>>>>                     class attempts to invoke the MethodHandle it
>>>>>>                     obtained from the classData:
>>>>>>
>>>>>>                     public void accept(java.lang.Object);
>>>>>>                     ? ? descriptor: (Ljava/lang/Object;)V
>>>>>>                     ? ? flags: (0x0001) ACC_PUBLIC
>>>>>>                     ? ? Code:
>>>>>>                     ? ? ? stack=3, locals=2, args_size=2
>>>>>>                     ? ? ? ? ?0: ldc ? ? #26 ? // Dynamic
>>>>>>                     #0:_:Ljava/lang/invoke/MethodHandle;
>>>>>>                     ? ? ? ? ?2: aload_0
>>>>>>                     ? ? ? ? ?3: getfield ? ?#13 // Field
>>>>>>                     arg$1:Lorg/wildfly/security/WildFlyElytronBaseProvider;
>>>>>>                     ? ? ? ? ?6: aload_1
>>>>>>                     ? ? ? ? ?7: checkcast ? ? #28 ? // class
>>>>>>                     java/security/Provider$Service
>>>>>>                     ? ? ? ? 10: invokevirtual #34 ? ? ? ? ? ? //
>>>>>>                     Method
>>>>>>                     java/lang/invoke/MethodHandle.invokeExact:(Lorg/wildfly/security/WildFlyElytronBaseProvider;Ljava/security/Provider$Service;)V
>>>>>>                     ? ? ? ? 13: return
>>>>>>
>>>>>>                     The scenario is during the assembly phase as
>>>>>>                     part of the indy resolution the MethodHandle
>>>>>>                     for which the exception is thrown gets created.
>>>>>>                     Normally MethodHandle's type gets added in
>>>>>>                     MethodType::internTable but by the time indy
>>>>>>                     resolution happens, JVM has already taken
>>>>>>                     snapshot of the MethodType::internTable
>>>>>>                     through an upcall to
>>>>>>                     MethodType::createArchivedObjects().
>>>>>>                     As a result the AOTCache ends up with the
>>>>>>                     MethodType object which is not in
>>>>>>                     AOTHolder.archivedMethodTypes.
>>>>>>
>>>>>>                     During the production run, when the jvm
>>>>>>                     invokes the MethodHandle, it searches for the
>>>>>>                     MethodType corresponding to the signature
>>>>>>                     passed at the callsite.
>>>>>>                     As expected, it fails to find it in the
>>>>>>                     AOTHolder.archivedMethodTypes, so it creates
>>>>>>                     a new instance of the MethodType.
>>>>>>                     But Invokers.checkExactType() relies on the
>>>>>>                     MethodHandle's?type to be the same object as
>>>>>>                     the MethodType object passed as parameter.
>>>>>>
>>>>>>                     static void checkExactType(MethodHandle mhM,
>>>>>>                     MethodType expected) {
>>>>>>                     ? ? MethodType targetType = mh.type();
>>>>>>                     ? ? ? ? if (targetType != expected)
>>>>>>                     ? ? ? ? ? ? throw
>>>>>>                     newWrongMethodTypeException(targetType,
>>>>>>                     expected);
>>>>>>                     ? ? }
>>>>>>
>>>>>>                     Hence, it throws
>>>>>>                     WrongMethodTypeException?though the two MT
>>>>>>                     objects have the same signature.
>>>>>>
>>>>>>                     To handle this scenario, I changed the order
>>>>>>                     of indy resolution and upcall to
>>>>>>                     MethodType::createArchivedObjects()?as:
>>>>>>
>>>>>>                     diff --git
>>>>>>                     a/src/hotspot/share/cds/metaspaceShared.cpp
>>>>>>                     b/src/hotspot/share/cds/metaspaceShared.cpp
>>>>>>                     index df4bcadefa3..457716cac5b 100644
>>>>>>                     --- a/src/hotspot/share/cds/metaspaceShared.cpp
>>>>>>                     +++ b/src/hotspot/share/cds/metaspaceShared.cpp
>>>>>>                     @@ -751,6 +751,20 @@ void
>>>>>>                     MetaspaceShared::link_shared_classes(bool
>>>>>>                     jcmd_request, TRAPS) {
>>>>>>                     ? ?if
>>>>>>                     (CDSConfig::is_dumping_final_static_archive()) {
>>>>>>                     ?FinalImageRecipes::apply_recipes(CHECK);
>>>>>>                     ? ?}
>>>>>>                     +
>>>>>>                     +#if INCLUDE_CDS_JAVA_HEAP
>>>>>>                     + ?if (CDSConfig::is_dumping_invokedynamic()) {
>>>>>>                     + ? ?// This makes sure that the MethodType
>>>>>>                     and MethodTypeForm tables won't be updated
>>>>>>                     + ? ?// concurrently when we are saving their
>>>>>>                     contents into a side table.
>>>>>>                     +
>>>>>>                     ?assert(CDSConfig::allow_only_single_java_thread(),
>>>>>>                     "Required");
>>>>>>                     +
>>>>>>                     + ? ?JavaValue result(T_VOID);
>>>>>>                     + ?JavaCalls::call_static(&result,
>>>>>>                     vmClasses::MethodType_klass(),
>>>>>>                     + vmSymbols::createArchivedObjects(),
>>>>>>                     + vmSymbols::void_method_signature(),
>>>>>>                     + ? ? ? ? CHECK);
>>>>>>                     + ?}
>>>>>>                     +#endif
>>>>>>                     ?}
>>>>>>                     Note that indy resolution happens as part of
>>>>>>                     FinalImageRecipes::apply_recipes(CHECK) which
>>>>>>                     is now invoked before the upcall to
>>>>>>                     createArchivedObjects().
>>>>>>                     With this change I am able to run the
>>>>>>                     application without any exceptions.
>>>>>>                     My complete patch can be seen here:
>>>>>>                     https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>>>>>                     <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>>>>>                     I will do more testing with this patch.
>>>>>>
>>>>>>                     @Ioi Lam <mailto:ioi.lam at oracle.com>?do you
>>>>>>                     have any feedback on this patch.
>>>>>>
>>>>>>                     Thanks,
>>>>>>                     - Ashutosh Mehra
>>>>>>
>>>>>>
>>>>>>
>>>>>>                     On Wed, Sep 11, 2024 at 10:14?AM Ashutosh
>>>>>>                     Mehra <asmehra at redhat.com> wrote:
>>>>>>
>>>>>>                         Hi Andrew,
>>>>>>                         Thanks for sharing the initial
>>>>>>                         investigation.
>>>>>>                         I have been looking into this and have a
>>>>>>                         few of things to add to your analysis:
>>>>>>
>>>>>>                         1.? As you mentioned the classData for
>>>>>>                         the lambda
>>>>>>                         class?WildFlyElytronBaseProvider$$Lambda
>>>>>>                         is null.
>>>>>>                         The classData is stored in the mirror
>>>>>>                         object of the InstanceKlass when the
>>>>>>                         class is defined
>>>>>>                         through?JVM_LookupDefineClass.
>>>>>>                         However, when we create the scratch
>>>>>>                         mirror object (which get stored in the
>>>>>>                         AOT cache) the classData is not populated.
>>>>>>                         See
>>>>>>                         https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp#L1128-L1131
>>>>>>                         <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp*L1128-L1131__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhbKjzG3gw$>
>>>>>>
>>>>>>                         Handle classData; // set to null. Will be
>>>>>>                         reinitialized at runtime
>>>>>>                         ? Handle mirror;
>>>>>>                         ? Handle comp_mirror;
>>>>>>                         allocate_mirror(k, /*is_scratch=*/true,
>>>>>>                         protection_domain, classData, mirror,
>>>>>>                         comp_mirror, CHECK);
>>>>>>
>>>>>>                         So this explains why the call to
>>>>>>                         classData(caller.lookupClass())returned null.
>>>>>>
>>>>>>                         2. In the mainline there is a check
>>>>>>                         in?InnerClassLambdaMetafactory.java for
>>>>>>                         the particular code pattern used by the
>>>>>>                         application.
>>>>>>                         If this code pattern is found then the
>>>>>>                         lambda proxy class is not included in the
>>>>>>                         CDS archive.
>>>>>>                         See
>>>>>>                         https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L163-L170
>>>>>>                         <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L163-L170__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZl2S9tQg$>
>>>>>>                         and
>>>>>>                         https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L246
>>>>>>                         <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L246__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhYsI3Xx0g$>
>>>>>>
>>>>>>                         ? ? ? // If the target class invokes a
>>>>>>                         protected method inherited from a
>>>>>>                         ? ? ? ? // superclass in a different
>>>>>>                         package, or does 'invokespecial', the
>>>>>>                         ? ? ? ? // lambda class has no access to
>>>>>>                         the resolved method, or does
>>>>>>                         ? ? ? ? // 'invokestatic' on a hidden
>>>>>>                         class which cannot be resolved by name.
>>>>>>                         ? ? ? ? // Instead, we need to pass the
>>>>>>                         live implementation method handle to
>>>>>>                         ? ? ? ? // the proxy class to invoke
>>>>>>                         directly. (javac prefers to avoid this
>>>>>>                         ? ? ? ? // situation by generating
>>>>>>                         bridges in the target class)
>>>>>>                         useImplMethodHandle =
>>>>>>                         (Modifier.isProtected(implInfo.getModifiers())
>>>>>>                         &&
>>>>>>                         ?!VerifyAccess.isSamePackage(targetClass,
>>>>>>                         implInfo.getDeclaringClass())) ||
>>>>>>                         ?implKind ==
>>>>>>                         MethodHandleInfo.REF_invokeSpecial ||
>>>>>>                         ?implKind ==
>>>>>>                         MethodHandleInfo.REF_invokeStatic &&
>>>>>>                         implClass.isHidden();
>>>>>>
>>>>>>                         In premain lambda proxy classes get
>>>>>>                         included in the AOT cache as a result of
>>>>>>                         indy resolution and that mechanism
>>>>>>                         doesn't have this kind of check.
>>>>>>
>>>>>>                         3. For the null classData problem
>>>>>>                         mentioned above, I tried to fix it by
>>>>>>                         storing classData in the scratch mirror
>>>>>>                         using the following patch:
>>>>>>
>>>>>>                         diff --git
>>>>>>                         a/src/hotspot/share/classfile/javaClasses.cpp
>>>>>>                         b/src/hotspot/share/classfile/javaClasses.cpp
>>>>>>                         index bd8141adbcc..41766e98093 100644
>>>>>>                         ---
>>>>>>                         a/src/hotspot/share/classfile/javaClasses.cpp
>>>>>>                         +++
>>>>>>                         b/src/hotspot/share/classfile/javaClasses.cpp
>>>>>>                         @@ -1094,9 +1094,9 @@ void
>>>>>>                         java_lang_Class::create_mirror(Klass* k,
>>>>>>                         Handle class_loader,
>>>>>>                         ? ? ?}
>>>>>>                         ? ? ?if (CDSConfig::is_dumping_heap()) {
>>>>>>                         ? ? ? ?if
>>>>>>                         (CDSConfig::is_dumping_protection_domains())
>>>>>>                         {
>>>>>>                         - ?create_scratch_mirror(k,
>>>>>>                         protection_domain, CHECK);
>>>>>>                         + ?create_scratch_mirror(k,
>>>>>>                         protection_domain, classData, CHECK);
>>>>>>                         ? ? ? ?} else {
>>>>>>                         - ?create_scratch_mirror(k, Handle() /*
>>>>>>                         null protection_domain*/, CHECK);
>>>>>>                         + ?create_scratch_mirror(k, Handle() /*
>>>>>>                         null protection_domain*/, classData, CHECK);
>>>>>>                         ? ? ? ?}
>>>>>>                         ? ? ?}
>>>>>>                         ? ?} else {
>>>>>>                         @@ -1117,7 +1117,7 @@ void
>>>>>>                         java_lang_Class::create_mirror(Klass* k,
>>>>>>                         Handle class_loader,
>>>>>>                         ?// Note: we archive the "scratch mirror"
>>>>>>                         instead of k->java_mirror(), because the
>>>>>>                         ?// latter may contain dumptime-specific
>>>>>>                         information that cannot be archived
>>>>>>                         ?// (e.g., ClassLoaderData*, or static
>>>>>>                         fields that are modified by Java code
>>>>>>                         execution).
>>>>>>                         -void
>>>>>>                         java_lang_Class::create_scratch_mirror(Klass*
>>>>>>                         k, Handle protection_domain, TRAPS) {
>>>>>>                         +void
>>>>>>                         java_lang_Class::create_scratch_mirror(Klass*
>>>>>>                         k, Handle protection_domain, Handle
>>>>>>                         classData, TRAPS) {
>>>>>>                         ? ?if (k->class_loader() != nullptr &&
>>>>>>                         ?k->class_loader() !=
>>>>>>                         SystemDictionary::java_platform_loader() &&
>>>>>>                         ?k->class_loader() !=
>>>>>>                         SystemDictionary::java_system_loader()) {
>>>>>>                         @@ -1125,9 +1125,11 @@ void
>>>>>>                         java_lang_Class::create_scratch_mirror(Klass*
>>>>>>                         k, Handle protection_domain,
>>>>>>                         ? ? ?return;
>>>>>>                         ? ?}
>>>>>>
>>>>>>                         - ?Handle classData; // set to null. Will
>>>>>>                         be reinitialized at runtime
>>>>>>                         + ?//Handle classData; // set to null.
>>>>>>                         Will be reinitialized at runtime
>>>>>>                         ? ?Handle mirror;
>>>>>>                         ? ?Handle comp_mirror;
>>>>>>                         ?allocate_mirror(k, /*is_scratch=*/true,
>>>>>>                         protection_domain, classData, mirror,
>>>>>>                         comp_mirror, CHECK);
>>>>>>
>>>>>>                         ? ?if (comp_mirror() != nullptr) {
>>>>>>                         diff --git
>>>>>>                         a/src/hotspot/share/classfile/javaClasses.hpp
>>>>>>                         b/src/hotspot/share/classfile/javaClasses.hpp
>>>>>>                         index bc49a0861a7..7ec2a2556dd 100644
>>>>>>                         ---
>>>>>>                         a/src/hotspot/share/classfile/javaClasses.hpp
>>>>>>                         +++
>>>>>>                         b/src/hotspot/share/classfile/javaClasses.hpp
>>>>>>                         @@ -263,7 +263,7 @@ class java_lang_Class
>>>>>>                         : AllStatic {
>>>>>>
>>>>>>                         ? ?// Archiving
>>>>>>                         ? ?static void
>>>>>>                         serialize_offsets(SerializeClosure* f)
>>>>>>                         NOT_CDS_RETURN;
>>>>>>                         - ?static void
>>>>>>                         create_scratch_mirror(Klass* k, Handle
>>>>>>                         protection_domain, TRAPS)
>>>>>>                         NOT_CDS_JAVA_HEAP_RETURN;
>>>>>>                         + ?static void
>>>>>>                         create_scratch_mirror(Klass* k, Handle
>>>>>>                         protection_domain, Handle classData,
>>>>>>                         TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>>>>>>                         ? ?static bool
>>>>>>                         restore_archived_mirror(Klass *k, Handle
>>>>>>                         class_loader, Handle module,
>>>>>>                         ? ? ? ?Handle protection_domain,
>>>>>>                         ? ? ? ?TRAPS)
>>>>>>                         NOT_CDS_JAVA_HEAP_RETURN_(false);
>>>>>>
>>>>>>                         But this resulted in a different exception:
>>>>>>
>>>>>>                         Exception in thread "main"
>>>>>>                         java.lang.ExceptionInInitializerError
>>>>>>                         at com.redhat.leyden.Main.main(Main.java:7)
>>>>>>                         Caused by:
>>>>>>                         java.lang.invoke.WrongMethodTypeException:
>>>>>>                         handle's method type
>>>>>>                         (WildFlyElytronBaseProvider,Service)void
>>>>>>                         but found
>>>>>>                         (WildFlyElytronBaseProvider,Service)void
>>>>>>                         at
>>>>>>                         java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>>>>>>                         at
>>>>>>                         java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>>>>>>                         at
>>>>>>                         java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
>>>>>>                         at
>>>>>>                         org.wildfly.security.WildFlyElytronBaseProvider$$Lambda/0x80000000c.accept(Unknown
>>>>>>                         Source)
>>>>>>                         at
>>>>>>                         org.wildfly.security.WildFlyElytronBaseProvider.putMakedPasswordImplementations(WildFlyElytronBaseProvider.java:112)
>>>>>>                         at
>>>>>>                         org.wildfly.security.WildFlyElytronBaseProvider.putPasswordImplementations(WildFlyElytronBaseProvider.java:107)
>>>>>>                         at
>>>>>>                         org.wildfly.security.password.WildFlyElytronPasswordProvider.<init>(WildFlyElytronPasswordProvider.java:43)
>>>>>>                         at
>>>>>>                         org.wildfly.security.password.WildFlyElytronPasswordProvider.<clinit>(WildFlyElytronPasswordProvider.java:36)
>>>>>>                         ... 1 more
>>>>>>
>>>>>>                         The exception message is strange because
>>>>>>                         the handle's method type and the expected
>>>>>>                         type are both symbolically the same.
>>>>>>                         I am debugging this exception at the moment.
>>>>>>                         Thanks,
>>>>>>                         - Ashutosh Mehra
>>>>>>
>>>>>>
>>>>>>                         On Wed, Sep 11, 2024 at 6:03?AM Andrew
>>>>>>                         Dinn <adinn at redhat.com> wrote:
>>>>>>
>>>>>>                             Oops, sorry, I debugged this a few
>>>>>>                             days ago! Correction to a few details:
>>>>>>
>>>>>>                             On 11/09/2024 10:39, Andrew Dinn wrote:
>>>>>>                             > A crash due to an NPE was observed
>>>>>>                             in the Infinispan (Data Grid) server
>>>>>>                             > app when deployed using the Leyden
>>>>>>                             EA. The crash still manifests with
>>>>>>                             > the latest premain code. The crash
>>>>>>                             happens below an application call
>>>>>>                             > which employs a method reference as
>>>>>>                             argument
>>>>>>                             >
>>>>>>                             >
>>>>>>                             putMakedPasswordImplementations(this::putService,
>>>>>>                             this);
>>>>>>
>>>>>>                             The called method in turn calls
>>>>>>                             consumer.accept
>>>>>>
>>>>>>                             ?consumer.accept(new Service(provider,
>>>>>>                             PASSWORD_FACTORY_TYPE, algorithm,
>>>>>>                             "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>>>>>                             emptyList,
>>>>>>                             emptyMap));
>>>>>>
>>>>>>                             which enters enters
>>>>>>                             MethodHandleNative::linkDynamicConstant()
>>>>>>
>>>>>>                             > Debugging shows that the call to
>>>>>>                             linkDynamicConstant() returns null.
>>>>>>                             >
>>>>>>                             > A simple reproducer for the problem
>>>>>>                             is available as a maven project on
>>>>>>                             > github:
>>>>>>                             >
>>>>>>                             >
>>>>>>                             https://github.com/tristantarrant/elytron-leyden
>>>>>>                             <https://urldefense.com/v3/__https://github.com/tristantarrant/elytron-leyden__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZaZr1akQ$>
>>>>>>                             >
>>>>>>                             > The ReadMe provides an explanation
>>>>>>                             of how to reproduce the problem. I
>>>>>>                             > did so and the debugged to find out
>>>>>>                             some of the details of what is
>>>>>>                             > happening (see below) but did not
>>>>>>                             fully clarify the problem. Help from
>>>>>>                             > someone more conversant with the
>>>>>>                             ins and outs of method handle
>>>>>>                             > bootstraps in premain would be
>>>>>>                             welcome. Details follow.
>>>>>>                             >
>>>>>>                             > regards,
>>>>>>                             >
>>>>>>                             >
>>>>>>                             > Andrew Dinn
>>>>>>                             > -----------
>>>>>>                             >
>>>>>>                             > I downloaded the git repo and
>>>>>>                             attached the Java sources using Maven
>>>>>>                             command
>>>>>>                             >
>>>>>>                             >? ? $ mvn dependency:sources
>>>>>>                             >
>>>>>>                             > Having manifested the crash by
>>>>>>                             following the instructions in the README
>>>>>>                             > I reran the leyden JVM under gdb
>>>>>>                             using the following commands to enable
>>>>>>                             > Java debugging
>>>>>>                             >
>>>>>>                             > $ gdb ${LEYDEN_HOME}/bin/java
>>>>>>                             > (gdb) cd /path/to/mvn/project
>>>>>>                             > (gdb) run
>>>>>>                             >
>>>>>>                             -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
>>>>>>
>>>>>>                             > -classpath
>>>>>>                             >
>>>>>>                             /home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/2.5.1.
>>>>>>                             <https://urldefense.com/v3/__http://2.5.1.__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhauJ-RjcQ$>Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar
>>>>>>                             -XX:CacheDataStore=elytron.aot
>>>>>>                             com.redhat.leyden.Main
>>>>>>                             >
>>>>>>                             > The problem manifests at
>>>>>>                             WildflyElytronBaseProvider.java:112
>>>>>>                             in method
>>>>>>                             >
>>>>>>                             WildflyElytronBaseProvider::putMakedPasswordImplementations
>>>>>>
>>>>>>                             ? ? ?static void
>>>>>>                             putMakedPasswordImplementations(Consumer<Service>
>>>>>>
>>>>>>                             consumer, Provider provider) {
>>>>>>                             ? ? ? ? ?for (String algorithm :
>>>>>>                             MASKED_ALGORITHMS) {
>>>>>>                             ?consumer.accept(new Service(provider,
>>>>>>                             PASSWORD_FACTORY_TYPE, algorithm,
>>>>>>                             "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>>>>>                             emptyList,
>>>>>>                             emptyMap)); <== NPE under this call
>>>>>>                             ? ? ? ? ?}
>>>>>>
>>>>>>
>>>>>>                             > The source code for this method can
>>>>>>                             be found in the following source jar
>>>>>>                             >
>>>>>>                             >
>>>>>>                             >
>>>>>>                             ${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar
>>>>>>                             >
>>>>>>                             > (where M2_REPO will normally be
>>>>>>                             ~/.m2/repository)
>>>>>>                             >
>>>>>>                             > Stepping into accept eventually
>>>>>>                             enters
>>>>>>                             MethodHandleNative::linkDynamicConstant
>>>>>>                             > which in turn enters into
>>>>>>                             ConstantBootstraps.makeConstant().
>>>>>>                             The caller
>>>>>>                             > Class at this point is a lambda
>>>>>>                             class which prints as
>>>>>>                             >
>>>>>>                             org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c
>>>>>>                             >
>>>>>>                             > Several steps further the code
>>>>>>                             enters BootstrapMethodInvoker::invoke
>>>>>>                             > (below the app method call but via
>>>>>>                             3 hidden frames) with bootstrapMethod
>>>>>>                             > bound to a DirectMethodHandle.
>>>>>>                             After several more steps this enters
>>>>>>                             >
>>>>>>                             DirectMethodHandle$Holder.invokeStatic
>>>>>>                             which in turn calls
>>>>>>                             >
>>>>>>                             MethodHandles::classData(Lookup,String,Class).
>>>>>>                             >
>>>>>>                             > At this point caller is a
>>>>>>                             MethodHandleLookup for the lambda class
>>>>>>                             > Lambda/0x800000000c mentioned
>>>>>>                             above. The following call
>>>>>>                             >
>>>>>>                             > Object classdata =
>>>>>>                             classData(caller.lookupClass());
>>>>>>                             >
>>>>>>                             > returns null to
>>>>>>                             DirectMethodHandle$Holder.invokeStatic
>>>>>>                             which pops the
>>>>>>                             > same result back out to
>>>>>>                             BootstrapMethodInvoker::invoke at line 90
>>>>>>                             >
>>>>>>                             > ??????????????? if (type instanceof
>>>>>>                             Class<?> c) {
>>>>>>                             > result =
>>>>>>                             bootstrapMethod.invoke(caller, name, c);
>>>>>>                             > <== null
>>>>>>                             >
>>>>>>                             > This null result pops back out as
>>>>>>                             the value for the call to
>>>>>>                             > BootstrapMethodInvoker.invoke(),
>>>>>>                             ConstantBootstraps.makeConstant() and
>>>>>>                             >
>>>>>>                             MethodHandleNative::linkDynamicConstant().
>>>>>>                             >
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240924/dfd815db/attachment.htm>

From duke at openjdk.org  Wed Sep 25 01:01:23 2024
From: duke at openjdk.org (duke)
Date: Wed, 25 Sep 2024 01:01:23 GMT
Subject: git: openjdk/leyden: hermetic-java-runtime: 199 new changesets
Message-ID: <fc4793a9-0567-4266-b5da-9351c661a607@openjdk.org>

Changeset: 79d76135
Branch: hermetic-java-runtime
Author:    Tejesh R <tr at openjdk.org>
Date:      2024-09-09 05:17:09 +0000
URL:       https://git.openjdk.org/leyden/commit/79d761358c5ee19b9028ad89d7c6a33dff6aa64a

8338153: java/awt/Checkbox/CheckboxCheckerScalingTest.java test failed on linux machine

Reviewed-by: abhiscxk, honkar

! test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java

Changeset: a18d9d84
Branch: hermetic-java-runtime
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-09-09 05:34:09 +0000
URL:       https://git.openjdk.org/leyden/commit/a18d9d84cd92b0b7e7c3c83efab1d81773e3a87c

8326616: tools/javac/patterns/Exhaustiveness.java intermittently Timeout signalled after 480 seconds

Reviewed-by: abimpoudis

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
! test/langtools/ProblemList.txt

Changeset: b45fe174
Branch: hermetic-java-runtime
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-09 05:53:29 +0000
URL:       https://git.openjdk.org/leyden/commit/b45fe174500f4bc38a0bb703c81614355404ae4f

8339710: Avoid initializing AccessFlag related classes in write-only cases

Reviewed-by: liach

! src/java.base/share/classes/jdk/internal/classfile/impl/DirectClassBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectFieldBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectMethodBuilder.java

Changeset: cb5c60b5
Branch: hermetic-java-runtime
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-09-09 06:42:05 +0000
URL:       https://git.openjdk.org/leyden/commit/cb5c60b530dd744e7d78ef69f15eef7521c4f1cc

8339591: Mark jdk/jshell/ExceptionMessageTest.java intermittent

Reviewed-by: lucy

! test/langtools/jdk/jshell/ExceptionMessageTest.java

Changeset: 4ff72dc5
Branch: hermetic-java-runtime
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-09-09 07:35:18 +0000
URL:       https://git.openjdk.org/leyden/commit/4ff72dc57e65e99b129f0ba28196994edf402018

8339487: ProcessHandleImpl os_getChildren sysctl call - retry in case of ENOMEM and enhance exception message

Reviewed-by: alanb, lucy, rriggs

! src/java.base/macosx/native/libjava/ProcessHandleImpl_macosx.c
! src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c

Changeset: 347d5728
Branch: hermetic-java-runtime
Author:    Stefan Johansson <sjohanss at openjdk.org>
Date:      2024-09-09 11:14:26 +0000
URL:       https://git.openjdk.org/leyden/commit/347d5728e69ae1f7d1a24820cc2c17bb0b8c0af5

8339387: ZGC: Synchronize medium page allocation

Reviewed-by: aboldtch, stefank, eosterlund

! src/hotspot/share/gc/z/zObjectAllocator.cpp
! src/hotspot/share/gc/z/zObjectAllocator.hpp

Changeset: 615a24f2
Branch: hermetic-java-runtime
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-09 11:56:34 +0000
URL:       https://git.openjdk.org/leyden/commit/615a24f216b80944fcef7eb5dd1c0c2fb4b45385

8338902: CDS flags are reported with wrong flag category

Reviewed-by: iklam, adinn

! src/hotspot/share/runtime/flags/allFlags.hpp

Changeset: 88cccc14
Branch: hermetic-java-runtime
Author:    Pavel Rappo <prappo at openjdk.org>
Date:      2024-09-09 12:06:21 +0000
URL:       https://git.openjdk.org/leyden/commit/88cccc14db168876a60b5ea2ae9d0fda7969af9a

8339631: Fix block @jls and @jvms tags

Reviewed-by: liach, darcy, jjg

! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/lang/Double.java
! src/java.base/share/classes/java/lang/Record.java
! src/java.base/share/classes/java/lang/StackWalker.java
! src/java.base/share/classes/java/lang/constant/PackageDesc.java
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/lang/reflect/AccessFlag.java
! src/java.base/share/classes/java/lang/reflect/InvocationHandler.java
! src/java.base/share/classes/java/lang/reflect/Method.java
! src/java.compiler/share/classes/javax/lang/model/element/NestingKind.java
! src/java.compiler/share/classes/javax/lang/model/type/NullType.java
! src/java.compiler/share/classes/javax/lang/model/type/TypeVariable.java
! src/jdk.compiler/share/classes/com/sun/source/tree/ClassTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/InstanceOfTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/LiteralTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/MethodTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/ModifiersTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/StatementTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/SwitchExpressionTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/VariableTree.java
! src/jdk.jshell/share/classes/jdk/jshell/Snippet.java

Changeset: c54fc08a
Branch: hermetic-java-runtime
Author:    Ferenc Rakoczi <ferenc.r.rakoczi at oracle.com>
Date:      2024-09-09 13:49:34 +0000
URL:       https://git.openjdk.org/leyden/commit/c54fc08aa3c63e4b26dc5edb2436844dfd3bab7c

8338587: Internal XOF Methods for SHAKE128 and SHAKE256

Reviewed-by: valeriep, weijun

! src/java.base/share/classes/sun/security/ec/ed/EdDSAParameters.java
! src/java.base/share/classes/sun/security/pkcs/PKCS7.java
! src/java.base/share/classes/sun/security/pkcs/SignerInfo.java
! src/java.base/share/classes/sun/security/provider/SHA3.java
- src/java.base/share/classes/sun/security/provider/SHAKE128.java
- src/java.base/share/classes/sun/security/provider/SHAKE256.java
! test/jdk/sun/security/ec/ed/TestEdOps.java
+ test/jdk/sun/security/provider/MessageDigest/SHAKEsqueeze.java
! test/lib/jdk/test/lib/security/SeededSecureRandom.java

Changeset: d53e405a
Branch: hermetic-java-runtime
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-09 14:18:20 +0000
URL:       https://git.openjdk.org/leyden/commit/d53e405a26e53086d46ce78a9792f0ca72cca529

8339742: Refactor ClassFileImpl to allow loading Option classes lazily

Reviewed-by: asotona

! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractDirectBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java

Changeset: 7c0f013d
Branch: hermetic-java-runtime
Author:    Oli Gillespie <ogillespie at openjdk.org>
Date:      2024-09-09 14:53:36 +0000
URL:       https://git.openjdk.org/leyden/commit/7c0f013d924a66c9cf55de761702b8de855e87fa

8339488: Extended NPE message doesn't handle CONSTANT_Dynamic

Reviewed-by: lmesnik, coleenp, simonis, liach

! src/hotspot/share/interpreter/bytecodeUtils.cpp
+ test/hotspot/jtreg/runtime/condy/CondyExtendedNullPointer.jasm
+ test/hotspot/jtreg/runtime/condy/CondyExtendedNullPointerTest.java

Changeset: a9bb0433
Branch: hermetic-java-runtime
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-09 15:15:16 +0000
URL:       https://git.openjdk.org/leyden/commit/a9bb04331df6788561921202cac73e35afbfe314

8339683: Simplify class data generation in InvokerBytecodeGenerator

Reviewed-by: redestad

! src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java

Changeset: 86a2f9c7
Branch: hermetic-java-runtime
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-09-09 16:04:59 +0000
URL:       https://git.openjdk.org/leyden/commit/86a2f9c7dcb6585cabf03c0940511d11560e85b7

8339644: Improve parsing of Day/Month in tzdata rules

Reviewed-by: jlu, coffeys

! make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java
! test/jdk/sun/util/calendar/zi/Month.java
! test/jdk/sun/util/calendar/zi/RuleDay.java

Changeset: 77468c28
Branch: hermetic-java-runtime
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-09-09 16:28:17 +0000
URL:       https://git.openjdk.org/leyden/commit/77468c284c068f921da543edd28333911e915b61

8339575: DumpingWithJavaAgent.java failed with missing expected output

Reviewed-by: ccheung, dholmes

! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/runtime/cds/appcds/StaticArchiveWithLambda.java
! test/hotspot/jtreg/runtime/cds/appcds/jvmti/dumpingWithAgent/DumpingWithJavaAgent.java

Changeset: 6b5958d6
Branch: hermetic-java-runtime
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-09-09 19:24:33 +0000
URL:       https://git.openjdk.org/leyden/commit/6b5958d6612a57c48320438981b2eae030927065

8339696: Clarify modeling scope of javax.lang.model.element

Reviewed-by: jjg, jlahoda, prappo

! src/java.compiler/share/classes/javax/lang/model/element/package-info.java

Changeset: 559fc711
Branch: hermetic-java-runtime
Author:    Evgeny Nikitin <enikitin at openjdk.org>
Committer: Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-09-09 19:55:45 +0000
URL:       https://git.openjdk.org/leyden/commit/559fc711e03cf0086bea399ffb40cf294cbbb6e1

8339366: [jittester] Make it possible to generate tests without execution

Reviewed-by: lmesnik

! test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/Automatic.java
! test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/ByteCodeGenerator.java
+ test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/IRTreeGenerator.java
! test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/JavaCodeGenerator.java
! test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/ProductionParams.java
! test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/TestsGenerator.java
! test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/utils/OptionResolver.java

Changeset: 56387a09
Branch: hermetic-java-runtime
Author:    Artur Barashev <artur.barashev at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
Date:      2024-09-09 21:04:04 +0000
URL:       https://git.openjdk.org/leyden/commit/56387a09810a3204ed820885e0ff0b26408be59d

8329754: The ThreadSafe attribute is ignored for SecureRandom algorithm aliases

Reviewed-by: weijun

! src/java.base/share/classes/java/security/SecureRandom.java
! test/jdk/java/security/SecureRandom/ThreadSafe.java

Changeset: 5e822c24
Branch: hermetic-java-runtime
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-09-10 06:13:36 +0000
URL:       https://git.openjdk.org/leyden/commit/5e822c24bb42e9027c8d9090d498bca7125d1963

8334870: javac does not accept classfiles with certain permitted RuntimeVisibleParameterAnnotations and RuntimeInvisibleParameterAnnotations attributes

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
- test/langtools/tools/javac/T6435291/T.jcod
- test/langtools/tools/javac/T6435291/T6435291.java
+ test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
! test/langtools/tools/javac/diags/examples.not-yet.txt

Changeset: 7e2bcf6d
Branch: hermetic-java-runtime
Author:    Alan Bateman <alanb at openjdk.org>
Date:      2024-09-10 07:23:35 +0000
URL:       https://git.openjdk.org/leyden/commit/7e2bcf6d0010161dfbc50da4031e65cb5482fb77

8338890: Add monitoring/management interface for the virtual thread scheduler

Reviewed-by: kevinw

! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/VirtualThread.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/share/classes/module-info.java
! src/jdk.management/share/classes/com/sun/management/internal/PlatformMBeanProviderImpl.java
+ src/jdk.management/share/classes/com/sun/management/internal/VirtualThreadSchedulerImpls.java
! src/jdk.management/share/classes/com/sun/management/package-info.java
+ src/jdk.management/share/classes/jdk/management/VirtualThreadSchedulerMXBean.java
+ src/jdk.management/share/classes/jdk/management/package-info.java
! src/jdk.management/share/classes/module-info.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/VThreadEventTest.java
! test/jdk/TEST.groups
! test/jdk/java/lang/Thread/virtual/JfrEvents.java
! test/jdk/java/lang/Thread/virtual/MonitorEnterExit.java
! test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java
! test/jdk/java/lang/Thread/virtual/ThreadAPI.java
! test/jdk/java/lang/Thread/virtual/VirtualThreadPinnedEventThrows.java
! test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking.java
! test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java
! test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java
+ test/jdk/jdk/management/VirtualThreadSchedulerMXBean/VirtualThreadSchedulerMXBeanTest.java
! test/lib/jdk/test/lib/thread/VThreadRunner.java

Changeset: 125f7432
Branch: hermetic-java-runtime
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-09-10 08:14:40 +0000
URL:       https://git.openjdk.org/leyden/commit/125f743223f2beb6e73f520c48a9a2de7ba5dce7

8305489: runtime/ErrorHandling/TestDwarf.java fails in some Linux configurations after JDK-8303805

Reviewed-by: dholmes, lmesnik

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

Changeset: 64de7813
Branch: hermetic-java-runtime
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-09-10 08:22:25 +0000
URL:       https://git.openjdk.org/leyden/commit/64de7813e4403f669fe9c02eabb204802f131367

8339587: runtime/reflect/ReflectOutOfMemoryError.java fails with "bootstrap method initialization exception"

Reviewed-by: lmesnik, ccheung

! test/hotspot/jtreg/runtime/reflect/ReflectOutOfMemoryError.java

Changeset: 0d8e52b3
Branch: hermetic-java-runtime
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-10 09:46:36 +0000
URL:       https://git.openjdk.org/leyden/commit/0d8e52b382432674533c9b80565eadf39ae83c64

8339800: Prefer invokeBasic in BootstrapMethodInvokers

Reviewed-by: jvernee

! src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java

Changeset: ad104932
Branch: hermetic-java-runtime
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-09-10 11:43:21 +0000
URL:       https://git.openjdk.org/leyden/commit/ad104932e6c26806c353ad048ce5cff7d2b4c29a

8338526: Don't store abstract and interface Klasses in class metaspace

Reviewed-by: stuefe, iklam

! src/hotspot/share/classfile/classFileParser.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdKlassQueue.cpp
! src/hotspot/share/memory/allocation.cpp
! src/hotspot/share/memory/metaspace.cpp
! src/hotspot/share/memory/metaspace.hpp
! src/hotspot/share/oops/annotations.hpp
! src/hotspot/share/oops/array.inline.hpp
! src/hotspot/share/oops/arrayKlass.cpp
! src/hotspot/share/oops/arrayKlass.hpp
! src/hotspot/share/oops/compressedKlass.hpp
! src/hotspot/share/oops/constMethod.hpp
! src/hotspot/share/oops/cpCache.hpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/oops/klass.hpp
! src/hotspot/share/oops/recordComponent.hpp
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! test/hotspot/jtreg/vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java

Changeset: 4d597de8
Branch: hermetic-java-runtime
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
Date:      2024-09-10 12:33:07 +0000
URL:       https://git.openjdk.org/leyden/commit/4d597de893dad79e74a280f3f9e82f0a14f9045d

8338930: StringConcatFactory hardCoded string concatenation strategy

Reviewed-by: redestad, liach

! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java

Changeset: fb51c1e5
Branch: hermetic-java-runtime
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-10 12:34:51 +0000
URL:       https://git.openjdk.org/leyden/commit/fb51c1e57b9bba876b6b5370c53abbd3196b8b2d

8339837: Remove unused BootstrapMethodsInvokers.isLambdaMetafactoryCondyBSM

Reviewed-by: jvernee

! src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java

Changeset: 38441b3f
Branch: hermetic-java-runtime
Author:    Quan Anh Mai <qamai at openjdk.org>
Date:      2024-09-10 12:44:57 +0000
URL:       https://git.openjdk.org/leyden/commit/38441b3f2d0e735089c29a9a9ce441b2d7c75db1

8339677: [vectorapi] YYYXXXVector::withLaneHelper and laneHelper should use Double::doubleToRawLongBits/Float::floatToRawIntBits

Reviewed-by: psandoz

! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template
! test/jdk/jdk/incubator/vector/Byte128VectorTests.java
! test/jdk/jdk/incubator/vector/Byte256VectorTests.java
! test/jdk/jdk/incubator/vector/Byte512VectorTests.java
! test/jdk/jdk/incubator/vector/Byte64VectorTests.java
! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Double128VectorTests.java
! test/jdk/jdk/incubator/vector/Double256VectorTests.java
! test/jdk/jdk/incubator/vector/Double512VectorTests.java
! test/jdk/jdk/incubator/vector/Double64VectorTests.java
! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Float128VectorTests.java
! test/jdk/jdk/incubator/vector/Float256VectorTests.java
! test/jdk/jdk/incubator/vector/Float512VectorTests.java
! test/jdk/jdk/incubator/vector/Float64VectorTests.java
! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Int128VectorTests.java
! test/jdk/jdk/incubator/vector/Int256VectorTests.java
! test/jdk/jdk/incubator/vector/Int512VectorTests.java
! test/jdk/jdk/incubator/vector/Int64VectorTests.java
! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Long128VectorTests.java
! test/jdk/jdk/incubator/vector/Long256VectorTests.java
! test/jdk/jdk/incubator/vector/Long512VectorTests.java
! test/jdk/jdk/incubator/vector/Long64VectorTests.java
! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Short128VectorTests.java
! test/jdk/jdk/incubator/vector/Short256VectorTests.java
! test/jdk/jdk/incubator/vector/Short512VectorTests.java
! test/jdk/jdk/incubator/vector/Short64VectorTests.java
! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java
! test/jdk/jdk/incubator/vector/templates/Kernel-With-Op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Get-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-With-Op.template
! test/jdk/jdk/incubator/vector/templates/Unit-header.template

Changeset: c246ede1
Branch: hermetic-java-runtime
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-10 13:33:19 +0000
URL:       https://git.openjdk.org/leyden/commit/c246ede163d675cfdacf741565195751981afb41

8339799: Reduce work done in j.l.invoke bytecode generators

Reviewed-by: liach

! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java

Changeset: 64a79d89
Branch: hermetic-java-runtime
Author:    Joakim Nordstr?m <jnordstrom at openjdk.org>
Date:      2024-09-10 13:49:13 +0000
URL:       https://git.openjdk.org/leyden/commit/64a79d898637e9255e6c1133dd684e272d84b95c

8335625: Update Javadoc for GetCpuLoad

Reviewed-by: alanb, kevinw

! src/jdk.management/share/classes/com/sun/management/OperatingSystemMXBean.java

Changeset: be0dca04
Branch: hermetic-java-runtime
Author:    Sandhya Viswanathan <sviswanathan at openjdk.org>
Date:      2024-09-10 15:53:23 +0000
URL:       https://git.openjdk.org/leyden/commit/be0dca046a43ecef2dcd012da6399cbed4cd0454

8339698: x86 unused andw/orw/xorw/addw encoding could be removed

Reviewed-by: kvn, jbhateja, qamai

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp

Changeset: 33525226
Branch: hermetic-java-runtime
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-09-10 16:28:04 +0000
URL:       https://git.openjdk.org/leyden/commit/33525226b97c80bf08c2e1ab9566aff5ac851fea

8338894: Deprecate jhsdb debugd for removal

Reviewed-by: cjplummer, alanb

! src/jdk.hotspot.agent/doc/index.html
! src/jdk.hotspot.agent/doc/transported_core.html
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/DebugServer.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HotSpotAgent.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java
! test/lib/jdk/test/lib/process/OutputAnalyzer.java

Changeset: 92431049
Branch: hermetic-java-runtime
Author:    Jasmine Karthikeyan <jkarthikeyan at openjdk.org>
Date:      2024-09-10 16:52:59 +0000
URL:       https://git.openjdk.org/leyden/commit/92431049fd1838ced2019366b7ccb37547ae6127

8335444: Generalize implementation of AndNode mul_ring

Reviewed-by: chagedorn, qamai, dfenacci

! src/hotspot/share/opto/mulnode.cpp
! test/hotspot/jtreg/compiler/c2/irTests/AndINodeIdealizationTests.java
! test/hotspot/jtreg/compiler/c2/irTests/AndLNodeIdealizationTests.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicBooleanOpTest.java
! test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java

Changeset: c8e64cb7
Branch: hermetic-java-runtime
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-09-10 17:27:19 +0000
URL:       https://git.openjdk.org/leyden/commit/c8e64cb7a578f1a32b48f76649fe19900ba6d040

8283779: Clarify API documentation of NetworkInterface with respect to configuration changes

Reviewed-by: alanb, msheppar

! src/java.base/share/classes/java/net/NetworkInterface.java

Changeset: 30645f33
Branch: hermetic-java-runtime
Author:    Fernando Guallini <fguallini at openjdk.org>
Committer: Jamil Nimeh <jnimeh at openjdk.org>
Date:      2024-09-10 18:48:58 +0000
URL:       https://git.openjdk.org/leyden/commit/30645f3309c040deb5bef71b1bd349942b4aa076

8338395: Add test coverage for instantiating NativePRNG with SecureRandomParameters

Reviewed-by: jnimeh

! test/jdk/sun/security/provider/SecureRandom/StrongSecureRandom.java

Changeset: 6fd043f1
Branch: hermetic-java-runtime
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-09-10 19:37:38 +0000
URL:       https://git.openjdk.org/leyden/commit/6fd043f1e4423b61cb5b85af9380f75e6a3846a2

8339789: Use index and definition tags in AnnotatedElement

Reviewed-by: jjg, prappo

! src/java.base/share/classes/java/lang/reflect/AnnotatedElement.java

Changeset: 9785e19f
Branch: hermetic-java-runtime
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-09-10 21:43:19 +0000
URL:       https://git.openjdk.org/leyden/commit/9785e19f3f87306cabc26a862d35b89d41cfef93

8339638: Update vmTestbase/nsk/jvmti/*Field*Watch tests to use virtual thread factory

Reviewed-by: cjplummer, sspitsyn

! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldAccessWatch/clrfldw001.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldModificationWatch/clrfmodw001.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001.java
+ test/lib/jdk/test/lib/thread/TestThreadFactory.java

Changeset: 07643237
Branch: hermetic-java-runtime
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-11 01:19:15 +0000
URL:       https://git.openjdk.org/leyden/commit/07643237d4a9c2da8a43dbdf0c6b32215827b741

8225049: Bad -Xlog example in -Xlog:help, online documentation, JEP

Reviewed-by: dholmes

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

Changeset: a6faf824
Branch: hermetic-java-runtime
Author:    SendaoYan <syan at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
Date:      2024-09-11 02:12:08 +0000
URL:       https://git.openjdk.org/leyden/commit/a6faf8247b58d73dca199fe1e8b0e914c415f67f

8339714: Delete tedious bool type define

Reviewed-by: jwaters, dholmes

! src/java.base/unix/native/libjsig/jsig.c
! src/utils/hsdis/binutils/hsdis-binutils.c

Changeset: 8fce5275
Branch: hermetic-java-runtime
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-11 05:27:08 +0000
URL:       https://git.openjdk.org/leyden/commit/8fce5275fc94ebc404a6a37f5ea0407140de63c1

8339810: Clean up the code in sun.tools.jar.Main to properly close resources and use ZipFile during extract

Reviewed-by: lancea

! src/jdk.jartool/share/classes/sun/tools/jar/Main.java

Changeset: ceef161e
Branch: hermetic-java-runtime
Author:    Joel Sikstr?m <joel.sikstrom at oracle.com>
Committer: Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-11 08:08:09 +0000
URL:       https://git.openjdk.org/leyden/commit/ceef161eea51578160b71b20826a9328f9a87a88

8339661: ZGC: Move some page resets and verification to callsites

Reviewed-by: stefank, eosterlund

! src/hotspot/share/gc/z/zForwarding.cpp
! src/hotspot/share/gc/z/zPage.cpp
! src/hotspot/share/gc/z/zPage.hpp
! src/hotspot/share/gc/z/zPageAllocator.cpp
! src/hotspot/share/gc/z/zRelocate.cpp
! test/hotspot/gtest/gc/z/test_zForwarding.cpp

Changeset: 0b3f2e64
Branch: hermetic-java-runtime
Author:    Casper Norrbin <casper.norrbin at oracle.com>
Committer: Johan Sj?len <jsjolen at openjdk.org>
Date:      2024-09-11 08:45:59 +0000
URL:       https://git.openjdk.org/leyden/commit/0b3f2e64e83b589115989f9d14a6c644bc3008aa

8339242: Fix overflow issues in AdlArena

Reviewed-by: jsjolen, kbarrett

! src/hotspot/share/adlc/adlArena.cpp
! src/hotspot/share/adlc/adlArena.hpp
! src/hotspot/share/memory/arena.cpp

Changeset: 59778885
Branch: hermetic-java-runtime
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-09-11 11:18:38 +0000
URL:       https://git.openjdk.org/leyden/commit/597788850042e7272a23714c05ba546ee6080856

8339686: java/foreign/TestMappedHandshake.java fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames
8339780: TestByteBuffer fails on AIX after 8339285

Reviewed-by: alanb, jvernee

! src/java.base/share/classes/java/nio/Buffer.java
! src/java.base/share/classes/java/nio/MappedByteBuffer.java
! src/java.base/share/classes/java/nio/MappedMemoryUtils.java
! src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java
+ src/java.base/share/classes/jdk/internal/access/foreign/MappedMemoryUtilsProxy.java
! src/java.base/share/classes/jdk/internal/foreign/MappedMemorySegmentImpl.java
! src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template

Changeset: 55a7cf14
Branch: hermetic-java-runtime
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2024-09-11 13:51:31 +0000
URL:       https://git.openjdk.org/leyden/commit/55a7cf14453b6cd1de91362927b2fa63cba400a1

8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected

Reviewed-by: stuefe, asmehra

! src/hotspot/os/linux/cgroupSubsystem_linux.cpp
! src/hotspot/os/linux/cgroupSubsystem_linux.hpp
! src/hotspot/os/linux/cgroupUtil_linux.cpp
! src/hotspot/os/linux/cgroupUtil_linux.hpp
! src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp
! src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp
! src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp
! src/hotspot/os/linux/cgroupV2Subsystem_linux.hpp
! test/hotspot/gtest/runtime/test_cgroupSubsystem_linux.cpp

Changeset: bfe7f920
Branch: hermetic-java-runtime
Author:    Robbin Ehn <rehn at openjdk.org>
Date:      2024-09-11 16:08:24 +0000
URL:       https://git.openjdk.org/leyden/commit/bfe7f9205b56483b4364130a3a87c58c3fc82998

8339741: RISC-V: C ABI breakage for integer on stack

Reviewed-by: fyang, luhenry

! src/hotspot/cpu/riscv/interpreterRT_riscv.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
+ test/hotspot/jtreg/compiler/calls/TestManyArgs.java
+ test/hotspot/jtreg/compiler/calls/libTestManyArgs.c

Changeset: d9fdf69c
Branch: hermetic-java-runtime
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2024-09-11 16:57:13 +0000
URL:       https://git.openjdk.org/leyden/commit/d9fdf69c34c20e0f2d526c2f04450acb904c3e80

8333446: Add tests for hierarchical container support

Reviewed-by: mbaesken, zzambers

! src/hotspot/share/prims/whitebox.cpp
! test/hotspot/jtreg/TEST.ROOT
+ test/hotspot/jtreg/containers/systemd/HelloSystemd.java
+ test/hotspot/jtreg/containers/systemd/SystemdMemoryAwarenessTest.java
! test/jdk/TEST.ROOT
! test/jtreg-ext/requires/VMProps.java
+ test/lib/jdk/test/lib/containers/systemd/SystemdRunOptions.java
+ test/lib/jdk/test/lib/containers/systemd/SystemdTestUtils.java
! test/lib/jdk/test/whitebox/WhiteBox.java

Changeset: 51b85a1f
Branch: hermetic-java-runtime
Author:    Brent Christian <bchristi at openjdk.org>
Date:      2024-09-11 19:02:05 +0000
URL:       https://git.openjdk.org/leyden/commit/51b85a1f692fed7a66bdc0fae21438a60aafe7c2

8339687: Rearrange reachabilityFence()s in jdk.test.lib.util.ForceGC

Reviewed-by: dholmes, smarks, kbarrett

! test/lib/jdk/test/lib/util/ForceGC.java

Changeset: 35a94b76
Branch: hermetic-java-runtime
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-09-11 19:27:00 +0000
URL:       https://git.openjdk.org/leyden/commit/35a94b769761bd923fe6db03be672f05c1a74c38

8339803: Acknowledge case insensitive unambiguous keywords in tzdata files

Reviewed-by: jlu, coffeys

! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java
! make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java
! test/jdk/sun/util/calendar/zi/RuleRec.java
! test/jdk/sun/util/calendar/zi/Zoneinfo.java

Changeset: 237a540f
Branch: hermetic-java-runtime
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-09-11 19:40:02 +0000
URL:       https://git.openjdk.org/leyden/commit/237a540f0161cb6c8e922e28482e9e35bc4aa81b

8339801: Add better test failure diagnostics to vmTestbase/nsk/jdi/EventRequestManager/threadStartRequests/thrstartreq002

Reviewed-by: lmesnik, amenkov, kevinw

! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/threadStartRequests/thrstartreq002.java

Changeset: 591aa7c5
Branch: hermetic-java-runtime
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
Date:      2024-09-11 19:41:43 +0000
URL:       https://git.openjdk.org/leyden/commit/591aa7c5c7ebe2a289ed25f0b26126e30fba23f3

8335362: [Windows] Stack pointer increment in _cont_thaw stub can cause program to terminate with exit code 0xc0000005

Reviewed-by: dholmes, fparain

! src/hotspot/os/windows/os_windows.inline.hpp
! src/hotspot/share/runtime/continuationFreezeThaw.cpp
! src/hotspot/share/runtime/stackOverflow.hpp
+ test/jdk/java/lang/Thread/virtual/BigStackChunk.java

Changeset: b0cff6b5
Branch: hermetic-java-runtime
Author:    Viktor Klang <vklang at openjdk.org>
Date:      2024-09-11 20:02:49 +0000
URL:       https://git.openjdk.org/leyden/commit/b0cff6b528af7a2de453dd05d1c9ecbe7e00dc20

8299419: Thread.sleep(millis) may throw OOME

Reviewed-by: alanb

! src/java.base/share/classes/java/lang/Thread.java
! src/java.base/share/classes/jdk/internal/event/ThreadSleepEvent.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadController.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/SleepingThread.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/thread/strace001.java

Changeset: c3711dc9
Branch: hermetic-java-runtime
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-09-11 22:06:23 +0000
URL:       https://git.openjdk.org/leyden/commit/c3711dc90980fb3e63ff199612c201c4464626bf

8339678: Update runtime/condy tests to be executed with VM flags

Reviewed-by: coleenp

! test/hotspot/jtreg/ProblemList-Xcomp.txt
! test/hotspot/jtreg/runtime/condy/BadBSMUseTest.java
! test/hotspot/jtreg/runtime/condy/CondyLDCTest.java
! test/hotspot/jtreg/runtime/condy/CondyNewInvokeSpecialTest.java
! test/hotspot/jtreg/runtime/condy/escapeAnalysis/TestEscapeCondy.java
! test/hotspot/jtreg/runtime/condy/staticInit/TestInitException.java

Changeset: 1d392492
Branch: hermetic-java-runtime
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-12 02:02:14 +0000
URL:       https://git.openjdk.org/leyden/commit/1d392492311daceeae12769cb9494eae63289853

8339834: Replace usages of -mx and -ms in some tests

Reviewed-by: aivanov, ascarpino, prr, dholmes

! src/java.base/share/classes/sun/security/util/Cache.java
! test/hotspot/jtreg/resourcehogs/compiler/intrinsics/string/TestStringIntrinsics2LargeArray.java
! test/jdk/java/beans/Introspector/8159696/UnloadClassBeanInfo.java
! test/jdk/java/beans/Introspector/Test5102804.java
! test/jdk/java/beans/Introspector/Test8027905.java
! test/jdk/java/beans/XMLEncoder/Test4646747.java
! test/jdk/java/lang/ref/SoftReference/Pin.java
! test/jdk/java/nio/Buffer/Chew.java
! test/jdk/tools/jimage/JImageToolTest.java

Changeset: 6d4bd6c6
Branch: hermetic-java-runtime
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-12 02:06:09 +0000
URL:       https://git.openjdk.org/leyden/commit/6d4bd6c6b6c3e6ef4c0a1e4eebf888156e43da58

8339835: Replace usages of -mx and -ms in some client-libs tests

Reviewed-by: azvegint, prr

! test/jdk/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java
! test/jdk/javax/print/PrintServiceLookup/FlushCustomClassLoader.java
! test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java
! test/jdk/javax/swing/JFileChooser/6396844/TwentyThousandTest.java
! test/jdk/javax/swing/JOptionPane/6464022/bug6464022.java
! test/jdk/javax/swing/UIDefaults/6795356/bug6795356.java
! test/jdk/javax/swing/border/TestTitledBorderLeak.java
! test/jdk/javax/swing/regtesthelpers/Util.java
! test/jdk/sun/java2d/Disposer/TestDisposerLeak.java
! test/jdk/sun/java2d/Disposer/TestDisposerRace.java
! test/jdk/sun/java2d/marlin/CrashTest.java

Changeset: cfbf74fc
Branch: hermetic-java-runtime
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-09-12 06:14:06 +0000
URL:       https://git.openjdk.org/leyden/commit/cfbf74fca493515495212d48a12ed109785eccc4

8339159: api/java_rmi/Naming/Rebind.html crashes with SEGV from UTF8::quoted_ascii_length call

Reviewed-by: iklam, aboldtch

! src/hotspot/share/classfile/symbolTable.cpp

Changeset: ac3f92b4
Branch: hermetic-java-runtime
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-09-12 07:06:53 +0000
URL:       https://git.openjdk.org/leyden/commit/ac3f92b4110b05906a49c4146774fd6324c6d198

8339731: java.desktop/share/classes/javax/swing/text/html/default.css typo in margin settings

Reviewed-by: prr

! src/java.desktop/share/classes/javax/swing/text/html/default.css

Changeset: 315abdf8
Branch: hermetic-java-runtime
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2024-09-12 07:19:54 +0000
URL:       https://git.openjdk.org/leyden/commit/315abdf8c835e95d9c509f72b7ae21e6b59e4a29

8339733: C2: some nodes can have incorrect control after do_range_check()

Reviewed-by: chagedorn, thartmann

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

Changeset: 3c40afa5
Branch: hermetic-java-runtime
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-09-12 08:31:18 +0000
URL:       https://git.openjdk.org/leyden/commit/3c40afa59c93860150960d478a9d2ffe33d4ce32

8334165: Remove serialVersionUID compatibility logic from JMX

Reviewed-by: dfuchs

! src/java.management/share/classes/javax/management/ClassAttributeValueExp.java
! src/java.management/share/classes/javax/management/MBeanAttributeInfo.java
! src/java.management/share/classes/javax/management/Notification.java
! src/java.management/share/classes/javax/management/NumericValueExp.java
! src/java.management/share/classes/javax/management/ObjectName.java
! src/java.management/share/classes/javax/management/modelmbean/DescriptorSupport.java
! src/java.management/share/classes/javax/management/modelmbean/InvalidTargetObjectTypeException.java
! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java
! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanConstructorInfo.java
! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanInfoSupport.java
! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanNotificationInfo.java
! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanOperationInfo.java
! src/java.management/share/classes/javax/management/modelmbean/XMLParseException.java
! src/java.management/share/classes/javax/management/relation/MBeanServerNotificationFilter.java
! src/java.management/share/classes/javax/management/relation/RelationNotification.java
! src/java.management/share/classes/javax/management/relation/RelationTypeSupport.java
! src/java.management/share/classes/javax/management/relation/Role.java
! src/java.management/share/classes/javax/management/relation/RoleInfo.java
! src/java.management/share/classes/javax/management/relation/RoleResult.java
! src/java.management/share/classes/javax/management/relation/RoleUnresolved.java
+ test/jdk/javax/management/ObjectName/SerialCompatRemovedTest.java
- test/jdk/javax/management/ObjectName/SerialCompatTest.java

Changeset: 1b17e0b1
Branch: hermetic-java-runtime
Author:    Alan Bateman <alanb at openjdk.org>
Date:      2024-09-12 08:48:17 +0000
URL:       https://git.openjdk.org/leyden/commit/1b17e0b133cab44029333c832bd046b338ede581

8338747: hasIncubatorModules needs to be generated when module resolution required at startup

Reviewed-by: iklam, ccheung

! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java

Changeset: 0765917d
Branch: hermetic-java-runtime
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-12 15:08:11 +0000
URL:       https://git.openjdk.org/leyden/commit/0765917dea9376586697012b60605099750d8d42

8340011: Simplify jdk.internal.classfile.impl.EntryMap

Reviewed-by: liach

! src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java
! src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java

Changeset: 4d65c3ef
Branch: hermetic-java-runtime
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-12 15:16:38 +0000
URL:       https://git.openjdk.org/leyden/commit/4d65c3efcaa5f855f9e0fbdd8e9d4f4ed2b44d3b

8339876: Move constant symbol caches to Utf8EntryImpl

Reviewed-by: redestad

! src/java.base/share/classes/java/lang/classfile/Annotation.java
! src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
! src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
! src/java.base/share/classes/java/lang/classfile/FieldModel.java
! src/java.base/share/classes/java/lang/classfile/MethodModel.java
! src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableInfo.java
! src/java.base/share/classes/java/lang/classfile/attribute/RecordComponentInfo.java
! src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java
! src/java.base/share/classes/java/lang/classfile/instruction/LocalVariable.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BoundLocalVariable.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedClassBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectClassBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectMethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/MethodImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java
! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java

Changeset: 7f1dae12
Branch: hermetic-java-runtime
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Date:      2024-09-12 15:24:22 +0000
URL:       https://git.openjdk.org/leyden/commit/7f1dae12e5e24d204a70cf610a8c482996556931

8339874: Avoid duplicate checking of trailing slash in ZipFile.getZipEntry

Reviewed-by: lancea, redestad

! src/java.base/share/classes/java/util/zip/ZipCoder.java
! src/java.base/share/classes/java/util/zip/ZipFile.java

Changeset: ab9b72c5
Branch: hermetic-java-runtime
Author:    Steve Dohrmann <sdohrmann at openjdk.org>
Date:      2024-09-12 16:06:16 +0000
URL:       https://git.openjdk.org/leyden/commit/ab9b72c50a5f324e53b8c6535f401cc185b98c75

8329035: New Data Destination instructions support

Reviewed-by: kvn, sviswanathan, jbhateja

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp

Changeset: 81ff91ef
Branch: hermetic-java-runtime
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-09-12 18:31:08 +0000
URL:       https://git.openjdk.org/leyden/commit/81ff91ef27a6a856ae2c453a9a9b8333b91da3ab

8339531: Improve performance of MemorySegment::mismatch

Reviewed-by: mcimadamore

! src/java.base/share/classes/java/lang/foreign/MemorySegment.java
! src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
+ src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java
! test/jdk/java/foreign/TestMismatch.java
- test/micro/org/openjdk/bench/java/lang/foreign/CopyTest.java
+ test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkCopy.java
+ test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkFill.java
+ test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkMismatch.java
- test/micro/org/openjdk/bench/java/lang/foreign/TestFill.java

Changeset: 5e5942a2
Branch: hermetic-java-runtime
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
Date:      2024-09-12 23:05:15 +0000
URL:       https://git.openjdk.org/leyden/commit/5e5942a282e14846404b68c65d43594d6b9226d9

8339794: Open source closed choice tests #1

Reviewed-by: jdv, prr

+ test/jdk/java/awt/Choice/ChoiceInsertTest.java
+ test/jdk/java/awt/Choice/ChoiceMouseDragTest.java
+ test/jdk/java/awt/Choice/WheelEventsConsumed.java

Changeset: ae75ca05
Branch: hermetic-java-runtime
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-13 05:47:44 +0000
URL:       https://git.openjdk.org/leyden/commit/ae75ca05e450da577e712eb7ed9dd9203616b80b

8314842: zgc/genzgc tests ignore vm flags

Reviewed-by: tschatzl, lmesnik

! test/hotspot/jtreg/gc/x/TestAllocateHeapAt.java
! test/hotspot/jtreg/gc/x/TestPageCacheFlush.java
! test/hotspot/jtreg/gc/x/TestSmallHeap.java
! test/hotspot/jtreg/gc/z/TestAllocateHeapAt.java
! test/hotspot/jtreg/gc/z/TestPageCacheFlush.java
! test/hotspot/jtreg/gc/z/TestSmallHeap.java

Changeset: b88ff9c9
Branch: hermetic-java-runtime
Author:    Andrew Dinn <adinn at openjdk.org>
Date:      2024-09-13 06:43:38 +0000
URL:       https://git.openjdk.org/leyden/commit/b88ff9c986bfe5e14e2ba5803a464fbf6e131df8

8339849: Enumerate opto and C1 stubs, generate enums, names, fields and generator calls

Reviewed-by: kvn

! src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp
! 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_Runtime1_aarch64.cpp
! src/hotspot/cpu/arm/c1_CodeStubs_arm.cpp
! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp
! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp
! src/hotspot/cpu/arm/c1_Runtime1_arm.cpp
! src/hotspot/cpu/ppc/c1_CodeStubs_ppc.cpp
! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp
! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp
! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/c1_Runtime1_ppc.cpp
! src/hotspot/cpu/riscv/c1_CodeStubs_riscv.cpp
! src/hotspot/cpu/riscv/c1_LIRAssembler_arraycopy_riscv.cpp
! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp
! src/hotspot/cpu/riscv/c1_LIRGenerator_riscv.cpp
! src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/c1_Runtime1_riscv.cpp
! src/hotspot/cpu/s390/c1_CodeStubs_s390.cpp
! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp
! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp
! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
! src/hotspot/cpu/s390/c1_Runtime1_s390.cpp
! src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp
! 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_Runtime1_x86.cpp
! src/hotspot/share/c1/c1_CodeStubs.hpp
! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/c1/c1_Runtime1.hpp
! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp
! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp
! src/hotspot/share/gc/x/c1/xBarrierSetC1.cpp
! src/hotspot/share/gc/z/c1/zBarrierSetC1.cpp
! src/hotspot/share/opto/escape.cpp
! src/hotspot/share/opto/runtime.cpp
! src/hotspot/share/opto/runtime.hpp
! src/hotspot/share/runtime/stubDeclarations.hpp
! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java
! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java

Changeset: 5709c379
Branch: hermetic-java-runtime
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-09-13 06:48:44 +0000
URL:       https://git.openjdk.org/leyden/commit/5709c379408d8919b86bbad6635b97756461ab27

8340081: Test java/foreign/TestLinker.java failed failed: missing permission java.lang.foreign.native.threshold.power.fill

Reviewed-by: dholmes

! src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java

Changeset: bacd0460
Branch: hermetic-java-runtime
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-09-13 08:05:19 +0000
URL:       https://git.openjdk.org/leyden/commit/bacd046062bffb4c95ec7a508a1080ad651a94a4

8321010: RISC-V: C2 RoundVF
8321011: RISC-V: C2 RoundVD

Reviewed-by: rehn, luhenry

! src/hotspot/cpu/riscv/assembler_riscv.hpp
! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.hpp
! src/hotspot/cpu/riscv/riscv.ad
! src/hotspot/cpu/riscv/riscv_v.ad
+ test/hotspot/jtreg/compiler/floatingpoint/TestRoundFloatAll.java
+ test/hotspot/jtreg/compiler/lib/golden/GoldenRound.java
+ test/hotspot/jtreg/compiler/vectorization/TestRoundVectRiscv64.java
+ test/hotspot/jtreg/compiler/vectorization/TestRoundVectorDoubleRandom.java
+ test/hotspot/jtreg/compiler/vectorization/TestRoundVectorFloatAll.java
+ test/hotspot/jtreg/compiler/vectorization/TestRoundVectorFloatRandom.java

Changeset: 0c36177f
Branch: hermetic-java-runtime
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-09-13 08:43:38 +0000
URL:       https://git.openjdk.org/leyden/commit/0c36177fead8b64a4cee9da3c895e3799f8ba231

8340089: Simplify SegmentBulkOperations::powerOfProperty

Reviewed-by: jpai

! src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java

Changeset: 358ff196
Branch: hermetic-java-runtime
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-13 11:22:39 +0000
URL:       https://git.openjdk.org/leyden/commit/358ff196336407484b1b892f08936e9378701959

8339727: Open source several AWT focus tests - series 1

Reviewed-by: honkar

! test/jdk/ProblemList.txt
+ test/jdk/java/awt/Focus/ActivateOnProperAppContextTest.java
+ test/jdk/java/awt/Focus/KillFocusTest.java
+ test/jdk/java/awt/Focus/TestDisabledAutoTransfer.java
+ test/jdk/java/awt/Focus/TestDisabledAutoTransferSwing.java

Changeset: 8a4ea09f
Branch: hermetic-java-runtime
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-09-13 12:04:31 +0000
URL:       https://git.openjdk.org/leyden/commit/8a4ea09fa220f74f2236fc85e197eadf83b65875

8336492: Regression in lambda serialization

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+ src/jdk.compiler/share/classes/com/sun/tools/javac/comp/CaptureScanner.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeScanner.java
! test/jdk/jdk/internal/vm/Continuation/Scoped.java
! test/langtools/tools/javac/MethodParameters/LambdaTest.out
! test/langtools/tools/javac/MethodParameters/LocalClassTest.out
! test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java
! test/langtools/tools/javac/classfiles/attributes/EnclosingMethod/EnclosingMethodTest.java
+ test/langtools/tools/javac/lambda/CaptureVarOrder.java
+ test/langtools/tools/javac/lambda/SerializedLambdaInLocalClass.java

Changeset: bd44cf8a
Branch: hermetic-java-runtime
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-09-13 12:10:11 +0000
URL:       https://git.openjdk.org/leyden/commit/bd44cf8ab709d08a4d015868bececabd0c97525b

8330302: strace004 can still fail

Reviewed-by: alanb, shade

! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadController.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/SleepingThread.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/thread/strace001.java

Changeset: 4d011785
Branch: hermetic-java-runtime
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-09-13 13:05:37 +0000
URL:       https://git.openjdk.org/leyden/commit/4d011785717c34fa5a245735968c60142fc14af4

8339927: Man page update for deprecating jhsdb debugd for removal

Reviewed-by: sspitsyn, cjplummer

! src/jdk.hotspot.agent/share/man/jhsdb.1

Changeset: 3c4d15bd
Branch: hermetic-java-runtime
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2024-09-13 14:13:47 +0000
URL:       https://git.openjdk.org/leyden/commit/3c4d15bdceaf94698af99d6b6fb12b3a28e13fdf

8334301: Errors in jpackage man page

Reviewed-by: almatvee

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

Changeset: 3e0da58e
Branch: hermetic-java-runtime
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-09-13 14:38:24 +0000
URL:       https://git.openjdk.org/leyden/commit/3e0da58ee6553fc0ed841db4a8800d50bc444517

8333843: Provide guidelines on MemorySegment to read strings with known lengths

Reviewed-by: mcimadamore

! src/java.base/share/classes/java/lang/foreign/MemorySegment.java

Changeset: 89ca89cb
Branch: hermetic-java-runtime
Author:    Calvin Cheung <ccheung at openjdk.org>
Date:      2024-09-13 14:59:35 +0000
URL:       https://git.openjdk.org/leyden/commit/89ca89cb26270a405226415c296dc45d3535e74d

8338626: ClassLoaderExt::process_jar_manifest() should allow / separator on Windows

Reviewed-by: iklam, dholmes, matsaave

! src/hotspot/share/classfile/classLoaderExt.cpp
! test/hotspot/jtreg/runtime/cds/appcds/ClassPathAttr.java

Changeset: 1a0a5388
Branch: hermetic-java-runtime
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-09-13 15:27:50 +0000
URL:       https://git.openjdk.org/leyden/commit/1a0a53883f7c6f523b5fefb722e137258d527362

8340120: Remove redundant code in SegmentBulkOperations::mismatch

Reviewed-by: mcimadamore

! src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java

Changeset: 89c172ac
Branch: hermetic-java-runtime
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-09-13 16:49:28 +0000
URL:       https://git.openjdk.org/leyden/commit/89c172ac47a9cc238739338417015bf912ad5424

8340082: Use inline return tag in java.base

Reviewed-by: iris, prappo, lancea, djelinski, naoto, liach

! src/java.base/share/classes/java/io/ObjectInputFilter.java
! src/java.base/share/classes/java/io/ObjectInputStream.java
! src/java.base/share/classes/java/lang/annotation/Retention.java
! src/java.base/share/classes/java/nio/charset/MalformedInputException.java
! src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java
! src/java.base/share/classes/java/time/format/TextStyle.java
! src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicBoolean.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicInteger.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLong.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLongArray.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReference.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java
! src/java.base/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java
! src/java.base/share/classes/java/util/concurrent/atomic/LongAccumulator.java
! src/java.base/share/classes/java/util/jar/Manifest.java
! src/java.base/share/classes/java/util/zip/Deflater.java
! src/java.base/share/classes/java/util/zip/Inflater.java
! src/java.base/share/classes/java/util/zip/ZipEntry.java
! src/java.base/share/classes/java/util/zip/ZipFile.java

Changeset: 37bf589e
Branch: hermetic-java-runtime
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-09-13 16:56:01 +0000
URL:       https://git.openjdk.org/leyden/commit/37bf589ec087c80851abb9d35910f09850cea9f6

8339847: Broken link to the dieharder distribution website in SplittableRandom

Reviewed-by: iris, liach

! src/java.base/share/classes/java/util/SplittableRandom.java

Changeset: 3aa8338f
Branch: hermetic-java-runtime
Author:    Erik Joelsson <erikj at openjdk.org>
Date:      2024-09-13 18:31:46 +0000
URL:       https://git.openjdk.org/leyden/commit/3aa8338f4e7d88967e77dfb0bace1c4b5add72f1

8340075: Autoconf bundle cannot run on read-only filesystem

Reviewed-by: mikael

! make/devkit/createAutoconfBundle.sh

Changeset: fdfe503d
Branch: hermetic-java-runtime
Author:    Valerie Peng <valeriep at openjdk.org>
Date:      2024-09-13 21:13:54 +0000
URL:       https://git.openjdk.org/leyden/commit/fdfe503d016086cf78b5a8c27dbe45f0261c68ab

8335288: SunPKCS11 initialization will call C_GetMechanismInfo on unsupported mechanisms

Reviewed-by: mbalao, weijun, hchao

! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java
+ test/jdk/sun/security/pkcs11/Provider/RequiredMechCheck.cfg
+ test/jdk/sun/security/pkcs11/Provider/RequiredMechCheck.java

Changeset: fa502ecd
Branch: hermetic-java-runtime
Author:    Manukumar V S <mvs at openjdk.org>
Date:      2024-09-14 05:08:57 +0000
URL:       https://git.openjdk.org/leyden/commit/fa502ecd2d1040ee2fe26d0ac5dd547379a0ade7

8339943: Frame not disposed in java/awt/dnd/DropActionChangeTest.java

Reviewed-by: prr, azvegint

! test/jdk/java/awt/dnd/DropActionChangeTest.java

Changeset: c91fa278
Branch: hermetic-java-runtime
Author:    Liang Mao <lmao at openjdk.org>
Date:      2024-09-14 05:36:47 +0000
URL:       https://git.openjdk.org/leyden/commit/c91fa278fe17ab204beef0fcef1ada6dd0bc37bb

8339725: Concurrent GC crashed due to GetMethodDeclaringClass

Reviewed-by: lmesnik, coleenp, eosterlund, stefank

! make/test/JtregNativeHotspot.gmk
! src/hotspot/share/prims/jvmtiEnv.cpp
! src/hotspot/share/prims/jvmtiEnvBase.cpp
+ test/hotspot/jtreg/serviceability/jvmti/GetMethodDeclaringClass/TestUnloadedClass.java
+ test/hotspot/jtreg/serviceability/jvmti/GetMethodDeclaringClass/libTestUnloadedClass.cpp

Changeset: a8f143c6
Branch: hermetic-java-runtime
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2024-09-14 22:50:50 +0000
URL:       https://git.openjdk.org/leyden/commit/a8f143c6abe7669c232cabda3a4e8df726de036e

8306679: com/sun/jdi/InterruptHangTest.java asserts with -Xcomp -Dmain.wrapper=Virtual options

Reviewed-by: lmesnik, cjplummer

! src/hotspot/share/runtime/continuationFreezeThaw.cpp
! test/jdk/ProblemList-Xcomp.txt

Changeset: a0794e0a
Branch: hermetic-java-runtime
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-16 03:48:55 +0000
URL:       https://git.openjdk.org/leyden/commit/a0794e0a054c5e7ed051efa6362726cdd7598255

8339639: Opensource few AWT PopupMenu tests

Reviewed-by: azvegint, prr

! test/jdk/ProblemList.txt
+ test/jdk/java/awt/PopupMenu/PopupHangTest.java
+ test/jdk/java/awt/PopupMenu/PopupMenuVisuals.java

Changeset: 0e0f10f9
Branch: hermetic-java-runtime
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-16 05:31:46 +0000
URL:       https://git.openjdk.org/leyden/commit/0e0f10f95217b5caaed02744a0a341350e4f2bc7

8340102: Move assert-only loop in OopMapSort::sort under debug macro

Reviewed-by: stuefe, fyang, kvn

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

Changeset: 74add0e2
Branch: hermetic-java-runtime
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-16 05:32:03 +0000
URL:       https://git.openjdk.org/leyden/commit/74add0e2e071a8c8e9547e5a1757b5950b780539

8340105: Expose BitMap::print_on in release builds

Reviewed-by: stuefe, stefank

! src/hotspot/share/utilities/bitMap.cpp
! src/hotspot/share/utilities/bitMap.hpp

Changeset: dc00eb87
Branch: hermetic-java-runtime
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-16 05:33:40 +0000
URL:       https://git.openjdk.org/leyden/commit/dc00eb87bc28ed5bf499af6835c3df474c454a41

8338912: CDS: Segmented roots array

Reviewed-by: ccheung, iklam

! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/archiveHeapLoader.cpp
! src/hotspot/share/cds/archiveHeapWriter.cpp
! src/hotspot/share/cds/archiveHeapWriter.hpp
! src/hotspot/share/cds/archiveUtils.cpp
! src/hotspot/share/cds/archiveUtils.hpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/filemap.hpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/heapShared.hpp

Changeset: 4b790637
Branch: hermetic-java-runtime
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-16 05:41:58 +0000
URL:       https://git.openjdk.org/leyden/commit/4b7906375b4bd11a480665110561180825c2dd9c

8339842: Open source several AWT focus tests - series 2

Reviewed-by: prr

+ test/jdk/java/awt/Focus/FocusChangeOnResizeTest.java
+ test/jdk/java/awt/Focus/LightweightFocusLostTest.java
+ test/jdk/java/awt/Focus/MixedWeightFocus.java
+ test/jdk/java/awt/Focus/NextFocusHelperTest.java

Changeset: 6be15c3d
Branch: hermetic-java-runtime
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2024-09-16 08:15:48 +0000
URL:       https://git.openjdk.org/leyden/commit/6be15c3d0bf0bb3625f2ecd43d7aa10e81f6edd8

8340012: [C2] assert(KlassEncodingMetaspaceMax > pd) failed: change encoding max if new encoding after 8338526

Reviewed-by: kvn, coleenp

! src/hotspot/share/ci/ciKlass.hpp
! src/hotspot/share/oops/compressedKlass.inline.hpp
! src/hotspot/share/opto/compile.cpp

Changeset: a4eb9a06
Branch: hermetic-java-runtime
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-16 08:34:54 +0000
URL:       https://git.openjdk.org/leyden/commit/a4eb9a063fb9e4a87923d464fe2c50ed5466acff

8339918: Remove checks for outdated -t -tm -Xfuture -checksource -cs -noasyncgc options from the launcher

Reviewed-by: dholmes, alanb

! src/java.base/share/classes/sun/launcher/resources/launcher.properties
! src/java.base/share/man/java.1
! src/java.base/share/native/libjli/java.c
! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java

Changeset: 54595188
Branch: hermetic-java-runtime
Author:    Johan Sj?len <jsjolen at openjdk.org>
Date:      2024-09-16 09:13:37 +0000
URL:       https://git.openjdk.org/leyden/commit/545951889c1ea68646be600decaf2bf4c049600b

8339627: Cleanup Unsafe.setMemory intrinsic code

Reviewed-by: tschatzl, fbredberg

! src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp
! src/hotspot/share/runtime/stubRoutines.hpp

Changeset: 05b9d479
Branch: hermetic-java-runtime
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-16 14:06:02 +0000
URL:       https://git.openjdk.org/leyden/commit/05b9d47905a0dd6dd7a042f940fe120d3a8338d1

8340194: Replace usage of -ms with -Xms in LauncherCommon.gmk make file

Reviewed-by: ihse, jwaters

! make/common/modules/LauncherCommon.gmk

Changeset: e1ebeef0
Branch: hermetic-java-runtime
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-16 14:08:08 +0000
URL:       https://git.openjdk.org/leyden/commit/e1ebeef0405ac6e48564a035767ee256291b9ca9

8340131: Refactor internal makeHiddenClassDefiner to take option mask instead of Set<ClassOption>

Reviewed-by: liach, jvernee

! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java

Changeset: 996790c7
Branch: hermetic-java-runtime
Author:    Volker Simonis <simonis at openjdk.org>
Date:      2024-09-16 14:55:53 +0000
URL:       https://git.openjdk.org/leyden/commit/996790c70f902d7840d0649a6b0867bed47c6537

8339954: Print JVMCI names with the Compiler.{perfmap,codelist,CodeHeap_Analytics} diagnostic commands

Reviewed-by: phh, dnsimon

! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/codeHeapState.cpp

Changeset: 1640bd26
Branch: hermetic-java-runtime
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-16 16:22:38 +0000
URL:       https://git.openjdk.org/leyden/commit/1640bd2676d8d183f02b4f5386ce42c47950e356

8340186: Shenandoah: Missing load_reference_barrier_phantom_narrow match in is_shenandoah_lrb_call

Reviewed-by: kvn

! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp

Changeset: 65b9abaa
Branch: hermetic-java-runtime
Author:    Justin Lu <jlu at openjdk.org>
Date:      2024-09-16 17:26:47 +0000
URL:       https://git.openjdk.org/leyden/commit/65b9abaa29eb9fe801b650ce787d98c31770a5dc

8339769: Incorrect error message during startup if working directory does not exist

Reviewed-by: naoto, dholmes, alanb

! src/java.base/unix/native/libjava/java_props_md.c

Changeset: 89759c8b
Branch: hermetic-java-runtime
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2024-09-16 18:08:09 +0000
URL:       https://git.openjdk.org/leyden/commit/89759c8b02ec73de0d734d10b16382109c7a8b45

8321935: Define the term 'standard doclet'

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/StandardDoclet.java

Changeset: 59407faf
Branch: hermetic-java-runtime
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-09-16 18:24:47 +0000
URL:       https://git.openjdk.org/leyden/commit/59407faf7b6861d142dbc3700a6fa9615567a275

8310525: DynamicLauncher for JDP test needs to try harder to find a free port

Reviewed-by: lmesnik, cjplummer

! test/jdk/sun/management/jdp/DynamicLauncher.java
! test/jdk/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java

Changeset: 858b4f12
Branch: hermetic-java-runtime
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
Committer: Y. Srinivas Ramakrishna <ysr at openjdk.org>
Date:      2024-09-16 19:15:30 +0000
URL:       https://git.openjdk.org/leyden/commit/858b4f127ad873666f51f4c54c37fa2d7801c32c

8339960: GenShen: Fix inconsistencies in generational Shenandoah behavior

Reviewed-by: wkemper, rkennke

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

Changeset: b26645f6
Branch: hermetic-java-runtime
Author:    Phil Race <prr at openjdk.org>
Date:      2024-09-16 19:28:20 +0000
URL:       https://git.openjdk.org/leyden/commit/b26645f64bb6dd3efafaceb92bedeaf8f93906e3

8339883: Open source several AWT/2D related tests

Reviewed-by: psadhukhan, honkar

+ test/jdk/java/awt/GraphicsConfiguration/NonDefaultGC.java
+ test/jdk/java/awt/GraphicsConfiguration/Position.java
+ test/jdk/sun/java2d/pipe/DrawImageBgTest.java
= test/jdk/sun/java2d/pipe/duke.gif

Changeset: 418bb42b
Branch: hermetic-java-runtime
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-09-16 20:03:00 +0000
URL:       https://git.openjdk.org/leyden/commit/418bb42b95b177f5f31f756054d0dd83740c6686

8340073: Support "%z" time zone abbreviation format in TZ files

Reviewed-by: jlu, joehw, coffeys

! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java
! src/java.base/share/classes/sun/util/cldr/CLDRTimeZoneNameProviderImpl.java

Changeset: 99d71850
Branch: hermetic-java-runtime
Author:    Denghui Dong <ddong at openjdk.org>
Date:      2024-09-17 00:13:47 +0000
URL:       https://git.openjdk.org/leyden/commit/99d7185071a5daa695adc6255d37ce382285a9b3

8340144: C1: remove unused Compilation::_max_spills

Reviewed-by: thartmann, shade

! src/hotspot/share/c1/c1_Compilation.cpp
! src/hotspot/share/c1/c1_Compilation.hpp

Changeset: 3e03e667
Branch: hermetic-java-runtime
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-17 00:56:31 +0000
URL:       https://git.openjdk.org/leyden/commit/3e03e6673acfea543d0dbbc64b7a4f52e3292c2b

8340176: Replace usage of -noclassgc with -Xnoclassgc in test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java

Reviewed-by: kevinw, lmesnik

! test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java

Changeset: a4cf1918
Branch: hermetic-java-runtime
Author:    Jatin Bhateja <jbhateja at openjdk.org>
Date:      2024-09-17 01:41:53 +0000
URL:       https://git.openjdk.org/leyden/commit/a4cf1918c963cbe0b0eee6db580f0769c0cbdbcc

8339793: Fix incorrect APX feature enabling with -XX:-UseAPX

Reviewed-by: kvn, thartmann, sviswanathan

! src/hotspot/cpu/x86/vm_version_x86.cpp

Changeset: 7849f252
Branch: hermetic-java-runtime
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-09-17 05:22:59 +0000
URL:       https://git.openjdk.org/leyden/commit/7849f252937dc774a1935cc4c68f2a46649f180b

8340184: Bug in CompressedKlassPointers::is_in_encodable_range

Reviewed-by: coleenp, rkennke, jsjolen

! src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/share/ci/ciKlass.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdKlassQueue.cpp
! src/hotspot/share/oops/compressedKlass.cpp
! src/hotspot/share/oops/compressedKlass.hpp
! src/hotspot/share/oops/compressedKlass.inline.hpp
! src/hotspot/share/utilities/globalDefinitions.hpp
+ test/hotspot/gtest/oops/test_compressedKlass.cpp
+ test/hotspot/jtreg/gtest/CompressedKlassGtest.java

Changeset: 10050a72
Branch: hermetic-java-runtime
Author:    Kangcheng Xu <kxu at openjdk.org>
Date:      2024-09-17 07:19:02 +0000
URL:       https://git.openjdk.org/leyden/commit/10050a723954926926650af65417d5b828cba387

8332442: C2: refactor Mod cases in Compile::final_graph_reshaping_main_switch()

Reviewed-by: roland, chagedorn, jkarthikeyan

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/divnode.cpp
! src/hotspot/share/opto/divnode.hpp
! src/hotspot/share/opto/node.hpp
+ test/hotspot/jtreg/compiler/c2/TestDivModNodes.java
! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java

Changeset: 7834662c
Branch: hermetic-java-runtime
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2024-09-17 08:11:22 +0000
URL:       https://git.openjdk.org/leyden/commit/7834662ca35aeb202d177fde1044add611240ecd

8340119: Remove oopDesc::size_might_change()

Reviewed-by: stefank, iwalulya

! src/hotspot/share/oops/oop.cpp
! src/hotspot/share/oops/oop.hpp
! src/hotspot/share/oops/oop.inline.hpp

Changeset: c6721a0f
Branch: hermetic-java-runtime
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-17 09:18:54 +0000
URL:       https://git.openjdk.org/leyden/commit/c6721a0fa2582c3ddf1ef0a6e16a09234432939c

8340009: Improve the output from assert_different_registers

Reviewed-by: aboldtch, dholmes, shade, mli

! src/hotspot/share/asm/register.hpp
! src/hotspot/share/utilities/debug.hpp

Changeset: 8b6e2770
Branch: hermetic-java-runtime
Author:    Daniel Lund?n <dlunden at openjdk.org>
Date:      2024-09-17 09:53:55 +0000
URL:       https://git.openjdk.org/leyden/commit/8b6e2770a53002fcc9e07d38b954e6854a644f95

8340273: Remove CounterHalfLifeTime

Reviewed-by: chagedorn, dholmes

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

Changeset: 269cd38b
Branch: hermetic-java-runtime
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2024-09-17 10:39:31 +0000
URL:       https://git.openjdk.org/leyden/commit/269cd38b55391364db0f92291eb29c3b6803db94

8338566: Lazy creation of exception instances is not thread safe

Reviewed-by: shade, kvn, dlong

! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/ci/ciEnv.hpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/memory/universe.hpp
! src/hotspot/share/runtime/threads.cpp

Changeset: 80db6e71
Branch: hermetic-java-runtime
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-09-17 11:58:58 +0000
URL:       https://git.openjdk.org/leyden/commit/80db6e71b092867212147bd369a9fda65dbd4b70

8339648: ZGC: Division by zero in rule_major_allocation_rate

Reviewed-by: aboldtch, lucy, tschatzl

! src/hotspot/share/gc/z/zDirector.cpp

Changeset: b39e6a84
Branch: hermetic-java-runtime
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-09-17 12:58:36 +0000
URL:       https://git.openjdk.org/leyden/commit/b39e6a84ef947661b5c878d02213da3a79bc026c

8329816: Add SLEEF version 3.6.1

Reviewed-by: erikj, mli, luhenry

! make/Main.gmk
+ make/UpdateSleefSource.gmk
! make/autoconf/basic_tools.m4
! make/autoconf/spec.gmk.template
+ src/jdk.incubator.vector/linux/legal/sleef.md
+ src/jdk.incubator.vector/linux/native/libsleef/README.md
+ src/jdk.incubator.vector/linux/native/libsleef/generated/misc.h
+ src/jdk.incubator.vector/linux/native/libsleef/generated/sleefinline_advsimd.h
+ src/jdk.incubator.vector/linux/native/libsleef/generated/sleefinline_rvvm1.h
+ src/jdk.incubator.vector/linux/native/libsleef/generated/sleefinline_sve.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/CHANGELOG.md
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/CMakeLists.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/CONTRIBUTORS.md
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/Configure.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/LICENSE.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/README.md
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/include/sleefdft.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/sleef-config.h.in
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/sleefConfig.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/CMakeLists.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperadvsimd.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperavx.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperavx2.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperavx2_128.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperavx512f.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperneon32.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperpower_128.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperpurec.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperpurec_scalar.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperrvv.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helpers390x_128.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helpersse2.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helpersve.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helpervecext.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/CMakeLists.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/addSuffix.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/arraymap.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/arraymap.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/common.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/common.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/commonfuncs.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/dd.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/df.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/estrin.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/f128util.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/keywords.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/main_checkfeature.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/misc.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/quaddef.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft-tester/CMakeLists.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft-tester/bench1d.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft-tester/fftwtest1d.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft-tester/fftwtest2d.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft-tester/measuredft.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft-tester/naivetest.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft-tester/roundtriptest1d.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft-tester/roundtriptest2d.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft-tester/tutorial.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft/CMakeLists.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft/dft.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft/dftcommon.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft/dftcommon.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft/mkdispatch.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft/mkunroll.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft/unroll0.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft/vectortype.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/Makefile
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/dp.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/gencoef.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/gencoef.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/ld.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/mkrempitab.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/mkrempitabqp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/qp.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/simplexfr.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/sp.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/Makefile
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/ProcessData.java
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/bench.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/benchsleef.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/benchsleef128.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/benchsleef256.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/benchsleef512.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/benchsvml.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/benchsvml128.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/benchsvml256.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/benchsvml512.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/measure.sh
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/CMakeLists.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/autovec.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/gnuabi_compatibility.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/hash_cinz.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/hash_finz.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/iut.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/iutcuda.cu
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/iutsimd.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/mveclibtest.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/tester.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/tester2dp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/tester2ld.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/tester2qp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/tester2simddp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/tester2simdsp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/tester2sp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/tester3.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/testerutil.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/testerutil.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/testervecabi.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/CMakeLists.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/dispatcher.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/dispavx.c.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/disppower_128.c.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/disps390x_128.c.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/dispscalar.c.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/dispscalar_footer.c.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/dispsse.c.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/funcproto.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/mkalias.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/mkdisp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/mkmasked_gnuabi.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/mkrename.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/mkrename_gnuabi.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/norename.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/rempitab.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/rename.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleef.pc.in
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleefdp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleefinline_cuda_header.h.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleefinline_header.h.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleefld.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleeflibm_footer.h.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleeflibm_header.h.org.in
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleefqp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleefsimddp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleefsimdsp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleefsp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/tryvsx3.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/tryvxe2.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/CMakeLists.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/hash_printf.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/qiutcuda.cu
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/qiutsimd.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/qtester.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/qtesterutil.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/qtesterutil.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/qutil.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/tester2printf.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/tester2simdqp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/tester3printf.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/CMakeLists.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/qdispatcher.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/qdispscalar.c.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/qdispx2.c.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/qfuncproto.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/qmkdisp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/qmkrename.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/rempitabqp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/sleefquad_footer.h.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/sleefquad_header.h.org.in
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/sleefquadinline_cuda_header.h.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/sleefquadinline_footer.h.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/sleefquadinline_header.h.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/sleefsimdqp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/aarch64-gcc.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/aarch64-llvm.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/armhf-gcc.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/armhf-llvm.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/native-gcc.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/native-llvm.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/ppc64el-gcc.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/ppc64el-llvm.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/riscv64-gcc.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/riscv64-llvm.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/s390x-gcc.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/s390x-llvm.cmake

Changeset: f8770163
Branch: hermetic-java-runtime
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-09-17 15:50:16 +0000
URL:       https://git.openjdk.org/leyden/commit/f87701635f82895fc10586e588f25e9c508e6979

8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win)

Reviewed-by: djelinski

! src/java.base/share/classes/java/nio/file/Path.java
! test/jdk/ProblemList.txt
! test/jdk/java/nio/file/Path/ToRealPath.java

Changeset: 64e3a9ee
Branch: hermetic-java-runtime
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-09-17 15:50:32 +0000
URL:       https://git.openjdk.org/leyden/commit/64e3a9ee91a6ae939e479a10cfc597e628c571e5

8339574: Behavior of File.is{Directory,File,Hidden} is not documented with respect to symlinks

Reviewed-by: djelinski, alanb

! src/java.base/share/classes/java/io/File.java
! src/java.base/share/classes/java/io/FileInputStream.java
! src/java.base/share/classes/java/io/FileOutputStream.java
! src/java.base/share/classes/java/io/RandomAccessFile.java

Changeset: 3e14fb9c
Branch: hermetic-java-runtime
Author:    David M. Lloyd <david.lloyd at redhat.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-09-17 16:24:38 +0000
URL:       https://git.openjdk.org/leyden/commit/3e14fb9c16e4ac3ad3c565059c534cfeacb45c7b

8340200: Misspelled constant `AttributesProcessingOption.DROP_UNSTABLE_ATRIBUTES`

Reviewed-by: liach

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

Changeset: 28d009ce
Branch: hermetic-java-runtime
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
Date:      2024-09-17 17:11:32 +0000
URL:       https://git.openjdk.org/leyden/commit/28d009ce0ecd4369351de859c491831b7f7bbb28

8339934: Simplify Math.scalb(double) method

Reviewed-by: darcy

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

Changeset: 90e92f98
Branch: hermetic-java-runtime
Author:    Jatin Bhateja <jbhateja at openjdk.org>
Date:      2024-09-17 17:46:36 +0000
URL:       https://git.openjdk.org/leyden/commit/90e92f98a6685b196b979853436668cf2b9f2117

8339790: Support Intel APX setzucc instruction

Reviewed-by: sviswanathan, jkarthikeyan, kvn

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/gc/x/x_x86_64.ad
! src/hotspot/cpu/x86/gc/z/z_x86_64.ad
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/x86_64.ad

Changeset: 5dc9723c
Branch: hermetic-java-runtime
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-17 18:13:54 +0000
URL:       https://git.openjdk.org/leyden/commit/5dc9723c8172e288872f744bac5fd2342475767a

8340323: Test jdk/classfile/OptionsTest.java fails after JDK-8340200

Reviewed-by: alanb

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

Changeset: d5881825
Branch: hermetic-java-runtime
Author:    Calvin Cheung <ccheung at openjdk.org>
Date:      2024-09-17 18:58:46 +0000
URL:       https://git.openjdk.org/leyden/commit/d5881825ef442cac7076d551f0182f16b17b0b53

8338686: App classpath mismatch if a jar from the Class-Path attribute is on the classpath

Reviewed-by: dholmes, iklam

! src/hotspot/share/classfile/classLoader.cpp
! test/hotspot/jtreg/runtime/cds/appcds/ClassPathAttr.java

Changeset: eabfc6e4
Branch: hermetic-java-runtime
Author:    Gerard Ziemski <gziemski at openjdk.org>
Date:      2024-09-17 19:59:06 +0000
URL:       https://git.openjdk.org/leyden/commit/eabfc6e4d901c53b93a78da740ca376607d9576d

8337563: NMT: rename MEMFLAGS to MemTag

Reviewed-by: dholmes, coleenp, jsjolen

! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/gc/g1/g1BatchedTask.hpp
! src/hotspot/share/gc/g1/g1MonotonicArena.cpp
! src/hotspot/share/gc/g1/g1MonotonicArena.hpp
! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp
! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.hpp
! 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/serial/serialBlockOffsetTable.cpp
! src/hotspot/share/gc/shared/cardTable.cpp
! src/hotspot/share/gc/shared/oopStorage.cpp
! src/hotspot/share/gc/shared/oopStorage.hpp
! src/hotspot/share/gc/shared/oopStorage.inline.hpp
! src/hotspot/share/gc/shared/oopStorageSet.cpp
! src/hotspot/share/gc/shared/oopStorageSet.hpp
! src/hotspot/share/gc/shared/partialArrayState.cpp
! src/hotspot/share/gc/shared/stringdedup/stringDedupProcessor.cpp
! src/hotspot/share/gc/shared/taskqueue.hpp
! src/hotspot/share/gc/shared/taskqueue.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp
! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.inline.hpp
! src/hotspot/share/gc/x/xVirtualMemory.cpp
! src/hotspot/share/gc/z/zNMT.cpp
! src/hotspot/share/jfr/leakprofiler/chains/jfrbitset.hpp
! src/hotspot/share/jfr/metadata/metadata.xml
! src/hotspot/share/jfr/periodic/jfrNativeMemoryEvent.cpp
! src/hotspot/share/jfr/periodic/jfrNativeMemoryEvent.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp
! src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp
! src/hotspot/share/memory/allocation.cpp
! src/hotspot/share/memory/allocation.hpp
! src/hotspot/share/memory/allocation.inline.hpp
! src/hotspot/share/memory/arena.cpp
! src/hotspot/share/memory/arena.hpp
! src/hotspot/share/memory/guardedMemory.cpp
! src/hotspot/share/memory/heap.cpp
! src/hotspot/share/memory/memRegion.cpp
! src/hotspot/share/memory/memRegion.hpp
! src/hotspot/share/memory/metaspace.cpp
! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp
! src/hotspot/share/memory/padded.hpp
! src/hotspot/share/memory/padded.inline.hpp
! src/hotspot/share/memory/resourceArea.hpp
! src/hotspot/share/memory/virtualspace.cpp
! src/hotspot/share/nmt/allocationSite.hpp
! src/hotspot/share/nmt/arrayWithFreeList.hpp
! src/hotspot/share/nmt/mallocHeader.cpp
! src/hotspot/share/nmt/mallocHeader.hpp
! src/hotspot/share/nmt/mallocHeader.inline.hpp
! src/hotspot/share/nmt/mallocLimit.cpp
! src/hotspot/share/nmt/mallocLimit.hpp
! src/hotspot/share/nmt/mallocSiteTable.cpp
! src/hotspot/share/nmt/mallocSiteTable.hpp
! src/hotspot/share/nmt/mallocTracker.cpp
! src/hotspot/share/nmt/mallocTracker.hpp
! src/hotspot/share/nmt/mallocTracker.inline.hpp
! src/hotspot/share/nmt/memBaseline.cpp
! src/hotspot/share/nmt/memBaseline.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/memReporter.hpp
+ src/hotspot/share/nmt/memTag.hpp
+ src/hotspot/share/nmt/memTagBitmap.hpp
! src/hotspot/share/nmt/memTracker.cpp
! src/hotspot/share/nmt/memTracker.hpp
! src/hotspot/share/nmt/memTracker.inline.hpp
- src/hotspot/share/nmt/memflags.hpp
! src/hotspot/share/nmt/memoryFileTracker.cpp
! src/hotspot/share/nmt/memoryFileTracker.hpp
! src/hotspot/share/nmt/nativeCallStackPrinter.hpp
! src/hotspot/share/nmt/nmtCommon.cpp
! src/hotspot/share/nmt/nmtCommon.hpp
! src/hotspot/share/nmt/nmtPreInit.cpp
! src/hotspot/share/nmt/nmtPreInit.hpp
! src/hotspot/share/nmt/nmtUsage.cpp
! src/hotspot/share/nmt/nmtUsage.hpp
! src/hotspot/share/nmt/virtualMemoryTracker.cpp
! src/hotspot/share/nmt/virtualMemoryTracker.hpp
! src/hotspot/share/nmt/vmatree.cpp
! src/hotspot/share/nmt/vmatree.hpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvmtiAgentList.hpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/handles.hpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/lightweightSynchronizer.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! src/hotspot/share/runtime/safepointMechanism.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/services/threadService.cpp
! src/hotspot/share/utilities/bitMap.cpp
! src/hotspot/share/utilities/bitMap.hpp
! src/hotspot/share/utilities/chunkedList.hpp
! src/hotspot/share/utilities/concurrentHashTable.hpp
! src/hotspot/share/utilities/concurrentHashTable.inline.hpp
! src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp
! src/hotspot/share/utilities/debug.cpp
! src/hotspot/share/utilities/growableArray.cpp
! src/hotspot/share/utilities/growableArray.hpp
! src/hotspot/share/utilities/linkedlist.hpp
! src/hotspot/share/utilities/objectBitSet.hpp
! src/hotspot/share/utilities/objectBitSet.inline.hpp
! src/hotspot/share/utilities/resizeableResourceHash.hpp
! src/hotspot/share/utilities/resourceHash.hpp
! src/hotspot/share/utilities/stack.hpp
! src/hotspot/share/utilities/stack.inline.hpp
! test/hotspot/gtest/nmt/test_arrayWithFreeList.cpp
! test/hotspot/gtest/nmt/test_nmt_cornercases.cpp
! test/hotspot/gtest/nmt/test_nmt_malloclimit.cpp
! test/hotspot/gtest/nmt/test_nmt_reserved_region.cpp
! test/hotspot/gtest/nmt/test_nmt_totals.cpp
! test/hotspot/gtest/nmt/test_vmatree.cpp
! test/hotspot/gtest/utilities/test_growableArray.cpp
! test/hotspot/gtest/utilities/test_resourceHash.cpp
! test/hotspot/gtest/utilities/test_utf8.cpp

Changeset: f0ae90f3
Branch: hermetic-java-runtime
Author:    Harshitha Onkar <honkar at openjdk.org>
Date:      2024-09-17 20:05:46 +0000
URL:       https://git.openjdk.org/leyden/commit/f0ae90f30c346544e87217ef1832d6a350fe1985

8340210: Add positionTestUI() to PassFailJFrame.Builder

Co-authored-by: Alexey Ivanov <aivanov at openjdk.org>
Reviewed-by: aivanov, azvegint

! test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

Changeset: dfc90938
Branch: hermetic-java-runtime
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-17 21:08:47 +0000
URL:       https://git.openjdk.org/leyden/commit/dfc90938ba36685ef58af0846ee4bdb214fa210f

8340132: Remove internal CpException for reading malformed utf8

Reviewed-by: asotona

! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java

Changeset: 202fd421
Branch: hermetic-java-runtime
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-09-17 22:36:37 +0000
URL:       https://git.openjdk.org/leyden/commit/202fd421f7e8b0f4a9c7393d1045e879acd13e64

8340213: jcmd VM.events ignores max argument

Reviewed-by: szaldana, cjplummer, amenkov, mli

! src/hotspot/share/services/diagnosticCommand.cpp
! test/hotspot/jtreg/serviceability/dcmd/vm/EventsTest.java

Changeset: 147e3007
Branch: hermetic-java-runtime
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-18 04:33:28 +0000
URL:       https://git.openjdk.org/leyden/commit/147e30070d8adbe65453a3a9316b9324890ea25f

8340015: Open source several AWT focus tests - series 7

Reviewed-by: honkar

! test/jdk/ProblemList.txt
+ test/jdk/java/awt/Focus/MinimizeNonfocusableWindowTest.java
+ test/jdk/java/awt/Focus/WindowDisposeFocusTest.java
+ test/jdk/java/awt/Focus/bug6435715.java

Changeset: d23c59e4
Branch: hermetic-java-runtime
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-18 07:01:13 +0000
URL:       https://git.openjdk.org/leyden/commit/d23c59e40812c9e3a5914193e68169dbdf6d09e5

8340280: Avoid calling MT.invokerType() when creating LambdaForms

Reviewed-by: liach, jvernee

! src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java
! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
! src/java.base/share/classes/java/lang/invoke/Invokers.java
! src/java.base/share/classes/java/lang/invoke/LambdaForm.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/java.base/share/classes/java/lang/invoke/NativeMethodHandle.java

Changeset: 5381f553
Branch: hermetic-java-runtime
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2024-09-18 07:07:45 +0000
URL:       https://git.openjdk.org/leyden/commit/5381f553ad61ddaa44d49c3039a05511cc68bdd0

8333258: C2: high memory usage in PhaseCFG::insert_anti_dependences()

Reviewed-by: kvn, epeter

! src/hotspot/share/opto/gcm.cpp
+ test/hotspot/jtreg/compiler/codegen/TestAntiDependenciesHighMemUsage.java
+ test/hotspot/jtreg/compiler/codegen/TestAntiDependenciesHighMemUsage2.java

Changeset: 3895b8fc
Branch: hermetic-java-runtime
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2024-09-18 08:26:33 +0000
URL:       https://git.openjdk.org/leyden/commit/3895b8fc0b2c6d187080dba6fe08297adad4a480

8340230: Tests crash: assert(is_in_encoding_range || k->is_interface() || k->is_abstract()) failed: sanity

Reviewed-by: thartmann, kvn

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

Changeset: 4ff17c14
Branch: hermetic-java-runtime
Author:    Simon Tooke <stooke at openjdk.org>
Date:      2024-09-18 09:11:40 +0000
URL:       https://git.openjdk.org/leyden/commit/4ff17c14a572a59b60d728c3626f430932eecea6

8319873: Add windows implementation for jcmd System.map and System.dump_map

Co-authored-by: Simon Tooke <stooke at openjdk.org>
Reviewed-by: stuefe, kevinw, szaldana

+ src/hotspot/os/windows/memMapPrinter_windows.cpp
! src/hotspot/share/nmt/memMapPrinter.cpp
! src/hotspot/share/nmt/memMapPrinter.hpp
! src/hotspot/share/services/diagnosticCommand.cpp
! src/hotspot/share/services/diagnosticCommand.hpp
! test/hotspot/jtreg/serviceability/dcmd/vm/SystemDumpMapTest.java
! test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java
! test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java
! test/jdk/sun/tools/jcmd/TestJcmdPIDSubstitution.java

Changeset: 45e438f3
Branch: hermetic-java-runtime
Author:    Nizar Benalla <nbenalla at openjdk.org>
Date:      2024-09-18 11:08:13 +0000
URL:       https://git.openjdk.org/leyden/commit/45e438f3f470c4af9d5066a4ae680f819bb3cde0

8339845: Update color.org and wapforum.org links to use HTTPS instead of HTTP

Reviewed-by: prr, honkar, aivanov

! src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java
! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java
! src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java
! src/java.desktop/share/classes/javax/imageio/package-info.java
! src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java

Changeset: 19b2cee4
Branch: hermetic-java-runtime
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-09-18 11:44:14 +0000
URL:       https://git.openjdk.org/leyden/commit/19b2cee42081e1f8e9c53e6c831ce1d2d2915fd5

8340113: Remove JULONG as a Diagnostic Command argument type (jcmd JFR.view)

Reviewed-by: lmesnik, egahlin

! src/hotspot/share/jfr/recorder/service/jfrOptionSet.cpp
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/ArgumentParser.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/DCmdView.java

Changeset: aeba1ea7
Branch: hermetic-java-runtime
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-09-18 12:03:00 +0000
URL:       https://git.openjdk.org/leyden/commit/aeba1ea7c44d6b378decf8557c8cd9fc7bfb7df5

8340272: C2 SuperWord: JMH benchmark for Reduction vectorization

Reviewed-by: kvn, jkarthikeyan

+ test/micro/org/openjdk/bench/vm/compiler/VectorReduction2.java

Changeset: 1d070a32
Branch: hermetic-java-runtime
Author:    Rafael Winterhalter <winterhalter at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-09-18 12:33:56 +0000
URL:       https://git.openjdk.org/leyden/commit/1d070a3238a1cd8b9359357e6e3f751cd26a3f06

8337302: Undefined type variable results in null

Reviewed-by: liach

! src/java.base/share/classes/java/lang/TypeNotPresentException.java
! src/java.base/share/classes/sun/reflect/generics/factory/CoreReflectionFactory.java
+ test/jdk/java/lang/reflect/Generics/TestMissingTypeVariable.java

Changeset: 08a2f841
Branch: hermetic-java-runtime
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-09-18 12:37:02 +0000
URL:       https://git.openjdk.org/leyden/commit/08a2f841ec78a10f8d6d54b2ac3a92e89f765f14

8339738: RISC-V: Vectorize crc32 intrinsic

Reviewed-by: fyang, luhenry

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

Changeset: 471a51a5
Branch: hermetic-java-runtime
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-18 13:46:19 +0000
URL:       https://git.openjdk.org/leyden/commit/471a51a5a4395f0bc6818c3c1d30455ce75500d6

8340368: windows-x64-slowdebug build fails after JDK-8319873

Reviewed-by: jpai, kevinw, aboldtch, eosterlund

! src/hotspot/os/windows/memMapPrinter_windows.cpp

Changeset: ae39a660
Branch: hermetic-java-runtime
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-09-18 14:38:06 +0000
URL:       https://git.openjdk.org/leyden/commit/ae39a6603c6c33a36dce30c3290a634b08a6bf05

8339992: RISC-V: some minor improvements of base64_vector_decode_round

Reviewed-by: fyang, luhenry

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

Changeset: 6ff287ad
Branch: hermetic-java-runtime
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-09-18 15:57:41 +0000
URL:       https://git.openjdk.org/leyden/commit/6ff287ad9aa45d8a37aafb4dd7bd9170280f5bbb

8340233: Missed ThreadWXEnable in jfrNativeLibraryLoadEvent.cpp

Reviewed-by: mgronlun

! src/hotspot/share/jfr/support/jfrNativeLibraryLoadEvent.cpp

Changeset: 9cfc03aa
Branch: hermetic-java-runtime
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-09-18 19:17:26 +0000
URL:       https://git.openjdk.org/leyden/commit/9cfc03aa81f2ae20616c8cc27e3467ad01cf985f

8340391: Windows jcmd System.map and System.dump_map tests failing

Reviewed-by: cjplummer

! test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java

Changeset: 31849127
Branch: hermetic-java-runtime
Author:    Harshitha Onkar <honkar at openjdk.org>
Date:      2024-09-18 19:25:11 +0000
URL:       https://git.openjdk.org/leyden/commit/31849127a06e448c705a61c536f51fc037bc4979

8339962: Open source AWT TextField tests - Set1

Reviewed-by: jdv, dnguyen, prr

+ test/jdk/java/awt/Label/ContainerValidateTest.java
+ test/jdk/java/awt/TextField/SetEchoCharTest.java
+ test/jdk/java/awt/TextField/SetEchoCharWordOpsTest.java

Changeset: 88a1c055
Branch: hermetic-java-runtime
Author:    Phil Race <prr at openjdk.org>
Date:      2024-09-18 20:39:40 +0000
URL:       https://git.openjdk.org/leyden/commit/88a1c0550e435888c571d32c577fd697652e5620

8340078: Open source several 2D tests

Reviewed-by: honkar

+ test/jdk/sun/java2d/GdiRendering/GdiBlitOffscreenTest.java
+ test/jdk/sun/java2d/GdiRendering/GdiLockTest.java
+ test/jdk/sun/java2d/SunGraphics2D/DrawRoundRect0Bug.java
+ test/jdk/sun/java2d/SunGraphics2D/RevalidateBug.java
+ test/jdk/sun/java2d/SunGraphics2D/ScaledPolyTest.java

Changeset: d9c67443
Branch: hermetic-java-runtime
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-19 01:44:45 +0000
URL:       https://git.openjdk.org/leyden/commit/d9c67443f7d7f03efb2837b63ee2acc6113f737f

8340360: Update -mx to -Xmx in UnninstallUIMemoryLeaks test

Reviewed-by: serb, prr

! test/jdk/javax/swing/UI/UnninstallUIMemoryLeaks/UnninstallUIMemoryLeaks.java

Changeset: 537447f8
Branch: hermetic-java-runtime
Author:    Amit Kumar <amitkumar at openjdk.org>
Date:      2024-09-19 04:33:01 +0000
URL:       https://git.openjdk.org/leyden/commit/537447f8816129dad9a1edd21bd30f3edf69ea60

8339980: [s390x] ProblemList jdk/java/util/zip/CloseInflaterDeflaterTest.java

Reviewed-by: lucy

! test/jdk/ProblemList.txt

Changeset: ac58b610
Branch: hermetic-java-runtime
Author:    Amit Kumar <amitkumar at openjdk.org>
Date:      2024-09-19 04:47:15 +0000
URL:       https://git.openjdk.org/leyden/commit/ac58b6102a26ac2ca7f6df5f176d5b5ca1d00d45

8339416: [s390x] Provide implementation for resolve_global_jobject

Reviewed-by: mdoerr, lucy

! src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
! src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.hpp
! src/hotspot/cpu/s390/gc/shared/modRefBarrierSetAssembler_s390.cpp
! src/hotspot/cpu/s390/gc/shared/modRefBarrierSetAssembler_s390.hpp
! src/hotspot/cpu/s390/macroAssembler_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.hpp

Changeset: 67198992
Branch: hermetic-java-runtime
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-19 06:28:05 +0000
URL:       https://git.openjdk.org/leyden/commit/67198992ce92da1ee615a73937f22fdaba28fba1

8286851: Deprecate for removal several of the undocumented java launcher options

Reviewed-by: dholmes

! src/java.base/share/native/libjli/java.c

Changeset: c58fbef0
Branch: hermetic-java-runtime
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-09-19 08:28:51 +0000
URL:       https://git.openjdk.org/leyden/commit/c58fbef05eace85a2e429da1ac8ff1ae09a0b736

8340276: Test java/lang/management/ThreadMXBean/Locks.java failed with NullPointerException

Reviewed-by: cjplummer, lmesnik

! test/jdk/java/lang/management/ThreadMXBean/Locks.java

Changeset: 118c9ade
Branch: hermetic-java-runtime
Author:    Serhiy Sachkov <serhiy.sachkov at oracle.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-19 08:39:11 +0000
URL:       https://git.openjdk.org/leyden/commit/118c9ade1a5e17d870415f689caa25af6524ab0e

8338759: Add extra diagnostic to java/net/InetAddress/ptr/Lookup.java

Reviewed-by: dfuchs, shade

! test/jdk/java/net/InetAddress/ptr/Lookup.java

Changeset: 8908812d
Branch: hermetic-java-runtime
Author:    Joel Sikstr?m <joel.sikstrom at oracle.com>
Committer: Hamlin Li <mli at openjdk.org>
Date:      2024-09-19 08:47:20 +0000
URL:       https://git.openjdk.org/leyden/commit/8908812d0a64f25f0d033d44725a69348789b223

8337674: ZGC: Consistent style for naming private static constants

Reviewed-by: stefank, aboldtch, mli

! src/hotspot/cpu/aarch64/gc/z/zAddress_aarch64.cpp
! src/hotspot/cpu/ppc/gc/z/zAddress_ppc.cpp
! src/hotspot/cpu/riscv/gc/z/zAddress_riscv.cpp
! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.hpp
! src/hotspot/cpu/x86/gc/z/z_x86_64.ad
! src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp
! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
! src/hotspot/share/gc/z/zBarrierSet.hpp
! src/hotspot/share/gc/z/zDirector.cpp
! src/hotspot/share/gc/z/zDirector.hpp
! src/hotspot/share/gc/z/zLiveMap.cpp
! src/hotspot/share/gc/z/zLiveMap.hpp
! src/hotspot/share/gc/z/zLiveMap.inline.hpp
! src/hotspot/share/gc/z/zReferenceProcessor.hpp
! src/hotspot/share/gc/z/zStackWatermark.cpp
! src/hotspot/share/gc/z/zStackWatermark.hpp
! src/hotspot/share/gc/z/zStat.cpp
! src/hotspot/share/gc/z/zStat.hpp
! src/hotspot/share/gc/z/zStoreBarrierBuffer.cpp
! src/hotspot/share/gc/z/zStoreBarrierBuffer.hpp
! src/hotspot/share/gc/z/zValue.hpp
! src/hotspot/share/gc/z/zValue.inline.hpp
! src/hotspot/share/gc/z/zVerify.cpp

Changeset: 2faf8b8d
Branch: hermetic-java-runtime
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-09-19 09:44:57 +0000
URL:       https://git.openjdk.org/leyden/commit/2faf8b8d582183275b1fdc92313a1c63c1753e80

8340007: Refactor KeyEvent/FunctionKeyTest.java

Reviewed-by: azvegint

! test/jdk/java/awt/event/KeyEvent/FunctionKeyTest.java

Changeset: 0120d3ee
Branch: hermetic-java-runtime
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-09-19 11:48:45 +0000
URL:       https://git.openjdk.org/leyden/commit/0120d3eed50bdc9fa53f2c41b31791620aeef613

8340306: Add border around instructions in PassFailJFrame

Reviewed-by: honkar, prr

! test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

Changeset: cecb0b3d
Branch: hermetic-java-runtime
Author:    Serhiy Sachkov <serhiy.sachkov at oracle.com>
Committer: Michael McMahon <michaelm at openjdk.org>
Date:      2024-09-19 12:08:31 +0000
URL:       https://git.openjdk.org/leyden/commit/cecb0b3d11ed0ce204cb6c3427f5a6858a844aeb

8339787: Add some additional diagnostic output to java/net/ipv6tests/UdpTest.java

Reviewed-by: dfuchs

! test/jdk/java/net/ipv6tests/Tests.java

Changeset: 7579d374
Branch: hermetic-java-runtime
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2024-09-19 12:29:21 +0000
URL:       https://git.openjdk.org/leyden/commit/7579d3740217e4a819cbf63837ec929f00464585

8338995: New Object to ObjectMonitor mapping: PPC64 implementation

Reviewed-by: rrich, lucy

! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
! src/hotspot/share/runtime/basicLock.inline.hpp

Changeset: c9bee173
Branch: hermetic-java-runtime
Author:    Prasadrao Koppula <pkoppula at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
Date:      2024-09-19 13:21:08 +0000
URL:       https://git.openjdk.org/leyden/commit/c9bee173d61f4accfc4adc280ab5d21600191756

8331391: Enhance the keytool code by invoking the buildTrustedCerts method for essential options

Reviewed-by: coffeys, mullan

! src/java.base/share/classes/sun/security/tools/keytool/Main.java

Changeset: d555f072
Branch: hermetic-java-runtime
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-09-19 14:15:45 +0000
URL:       https://git.openjdk.org/leyden/commit/d555f072b2036664711242a242a35fb30d277e5a

8298614: Support CDS heap dumping for SerialGC and ParallelGC

Reviewed-by: dholmes, lmesnik, iklam

! src/hotspot/share/cds/archiveHeapWriter.cpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/heapShared.hpp
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/IncompatibleOptions.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsHumongous.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsUtils.java

Changeset: 3bb8de31
Branch: hermetic-java-runtime
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-09-19 14:18:03 +0000
URL:       https://git.openjdk.org/leyden/commit/3bb8de31457a544d9c20a12f8d8d30d6d1cd9cba

8338693: assert(Atomic::add(&ik->_shared_class_load_count, 1) == 1) failed: shared class loaded more than once

Reviewed-by: iklam, dholmes

! src/hotspot/share/classfile/systemDictionary.cpp

Changeset: 2ada313c
Branch: hermetic-java-runtime
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-09-19 15:25:04 +0000
URL:       https://git.openjdk.org/leyden/commit/2ada313cdd9a20ed33f7e0a7298c8a0e69a81c6f

8340329: (fs) Message of NotLinkException thrown by FIles.readSymbolicLink does not include file name (win)

Reviewed-by: alanb

! src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java
! test/jdk/java/nio/file/Files/Links.java

Changeset: 5f3e7aa8
Branch: hermetic-java-runtime
Author:    Justin Lu <jlu at openjdk.org>
Date:      2024-09-19 16:18:37 +0000
URL:       https://git.openjdk.org/leyden/commit/5f3e7aa83348edafb83480ce67d0c58c46e11b24

8339735: Remove references to Applet in core-libs/security APIs

Reviewed-by: coffeys, naoto, iris, rriggs, lancea, mullan

! src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html
! src/java.base/share/classes/java/net/HttpURLConnection.java
! src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java
! src/java.base/share/classes/javax/crypto/CryptoPermission.java
! src/java.base/share/classes/javax/crypto/ExemptionMechanism.java
! src/java.base/share/classes/javax/crypto/JceSecurityManager.java
! src/java.base/share/classes/javax/net/SocketFactory.java

Changeset: bc36ace7
Branch: hermetic-java-runtime
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-19 16:22:17 +0000
URL:       https://git.openjdk.org/leyden/commit/bc36ace72c1189dcd6d0c05d40d8c568acd89b01

8340271: Open source several AWT Robot tests

Reviewed-by: abhiscxk, honkar

+ test/jdk/java/awt/Robot/CreateScreenCapture.java
+ test/jdk/java/awt/Robot/RobotScrollTest.java

Changeset: d1d82400
Branch: hermetic-java-runtime
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-09-19 16:59:51 +0000
URL:       https://git.openjdk.org/leyden/commit/d1d824008d1dc70029013820814fd03c40b4e309

8340308: PassFailJFrame: Make rows default to number of lines in instructions

Reviewed-by: honkar, azvegint

! test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

Changeset: ec3cba02
Branch: hermetic-java-runtime
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-09-19 17:10:23 +0000
URL:       https://git.openjdk.org/leyden/commit/ec3cba02963b5128480bcf62431ab03ecdb26db6

8340399: Update comment in SourceVersion for language evolution history

Reviewed-by: iris

! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java

Changeset: 15ae1155
Branch: hermetic-java-runtime
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-19 17:47:08 +0000
URL:       https://git.openjdk.org/leyden/commit/15ae1155a11b401e3d1dd39177c209f17f077119

8340166: [REDO] CDS: Trim down minimum GC region alignment

Reviewed-by: ccheung, iklam

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

Changeset: 75d5e117
Branch: hermetic-java-runtime
Author:    William Kemper <wkemper at openjdk.org>
Date:      2024-09-19 17:55:23 +0000
URL:       https://git.openjdk.org/leyden/commit/75d5e117770590d2432fcfe8d89734c7038d4e55

8340400: Shenandoah: Whitebox breakpoint GC requests may cause assertions

Reviewed-by: shade

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

Changeset: fde85083
Branch: hermetic-java-runtime
Author:    Alexander Zuev <kizune at openjdk.org>
Date:      2024-09-19 19:51:05 +0000
URL:       https://git.openjdk.org/leyden/commit/fde8508379d2983fa70784faef60699c81f9c359

8339902: Open source couple TextField related tests

Reviewed-by: honkar

+ test/jdk/java/awt/TextField/CaretPositionTest/CaretPositionTest.java
+ test/jdk/java/awt/TextField/SetBoundsTest/SetBoundsTest.java
+ test/jdk/java/awt/TextField/SetEchoCharTest4/SetEchoCharTest4.java
+ test/jdk/java/awt/TextField/SetPasswordTest/SetPasswordTest.java
+ test/jdk/java/awt/TextField/ZeroEchoCharTest/ZeroEchoCharTest.java

Changeset: 296b4963
Branch: hermetic-java-runtime
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-09-19 21:06:46 +0000
URL:       https://git.openjdk.org/leyden/commit/296b49634eed83bca6cfdee514b9c7c4f8252d59

8340353: Remove CompressedOops::ptrs_base

Reviewed-by: stefank, coleenp, shade, mli

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/share/oops/compressedOops.hpp

Changeset: fdc16a37
Branch: hermetic-java-runtime
Author:    Phil Race <prr at openjdk.org>
Date:      2024-09-19 22:20:05 +0000
URL:       https://git.openjdk.org/leyden/commit/fdc16a373459cb2311316448c765b1bee5c73694

8340480: Bad copyright notices in changes from JDK-8339902

Reviewed-by: kcr, bpb, kizune

! test/jdk/java/awt/TextField/CaretPositionTest/CaretPositionTest.java
! test/jdk/java/awt/TextField/SetBoundsTest/SetBoundsTest.java
! test/jdk/java/awt/TextField/SetEchoCharTest4/SetEchoCharTest4.java
! test/jdk/java/awt/TextField/SetPasswordTest/SetPasswordTest.java
! test/jdk/java/awt/TextField/ZeroEchoCharTest/ZeroEchoCharTest.java

Changeset: 969c2af9
Branch: hermetic-java-runtime
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-09-19 23:45:26 +0000
URL:       https://git.openjdk.org/leyden/commit/969c2af95387992c55a2e1768de848a354e74127

8339192: Native annotation parsing code of deprecated annotations causes crash

Reviewed-by: jrose, mgronlun

! src/hotspot/share/classfile/classFileParser.cpp
+ test/hotspot/jtreg/runtime/Annotations/BadContendedGroupBadCPIndex.jcod
+ test/hotspot/jtreg/runtime/Annotations/BadContendedGroupWrongType.jcod
+ test/hotspot/jtreg/runtime/Annotations/BadDeprecatedExtraMemberAtEnd.jcod
+ test/hotspot/jtreg/runtime/Annotations/BadDeprecatedExtraMemberAtStart.jcod
+ test/hotspot/jtreg/runtime/Annotations/BadDeprecatedForRemovalBadCPIndex.jcod
+ test/hotspot/jtreg/runtime/Annotations/BadDeprecatedForRemovalWrongType.jcod
+ test/hotspot/jtreg/runtime/Annotations/BadDeprecatedSinceWrongType.jcod
+ test/hotspot/jtreg/runtime/Annotations/TestBadAnnotations.java

Changeset: 94c33179
Branch: hermetic-java-runtime
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-20 03:05:22 +0000
URL:       https://git.openjdk.org/leyden/commit/94c33179b6a1205100d7c125f3a7c11e29621db9

8339895: Open source several AWT focus tests - series 3

Reviewed-by: prr

! test/jdk/ProblemList.txt
+ test/jdk/java/awt/Focus/ActivateFocusTest.java
+ test/jdk/java/awt/Focus/CanvasPanelFocusOnClickTest.java
+ test/jdk/java/awt/Focus/FocusPolicyTest.java
+ test/jdk/java/awt/Focus/RequestInInactiveFrame.java

Changeset: 0f7d9e59
Branch: hermetic-java-runtime
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-09-20 04:15:55 +0000
URL:       https://git.openjdk.org/leyden/commit/0f7d9e599593bb8e31e7e33a559d25ec803c7ba4

8340436: Remove unused CompressedOops::AnyNarrowOopMode

Reviewed-by: haosun, dholmes

! src/hotspot/share/oops/compressedOops.hpp

Changeset: f4e40179
Branch: hermetic-java-runtime
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Date:      2024-09-20 04:19:12 +0000
URL:       https://git.openjdk.org/leyden/commit/f4e401791efb920b9773f2886b34904c95106727

8339984: Open source AWT MenuItem related tests

Reviewed-by: aivanov

+ test/jdk/java/awt/MenuItem/GiantFontTest.java
+ test/jdk/java/awt/MenuItem/LotsOfMenuItemsTest.java
+ test/jdk/java/awt/MenuItem/MenuSetFontTest.java
+ test/jdk/java/awt/MenuItem/NullOrEmptyStringLabelTest.java
+ test/jdk/java/awt/MenuItem/UnicodeMenuItemTest.java

Changeset: 46b02f49
Branch: hermetic-java-runtime
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-20 06:06:27 +0000
URL:       https://git.openjdk.org/leyden/commit/46b02f49bcc730d94e37cf17fa996fdd12bdb990

8339906: Open source several AWT focus tests - series 4

Reviewed-by: abhiscxk, prr

+ test/jdk/java/awt/Focus/AltTabEventsTest.java
+ test/jdk/java/awt/Focus/ComponentLostFocusTest.java
+ test/jdk/java/awt/Focus/FocusKeepTest.java
+ test/jdk/java/awt/Focus/KeyStrokeTest.java

Changeset: 9d76c7c6
Branch: hermetic-java-runtime
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-20 07:00:38 +0000
URL:       https://git.openjdk.org/leyden/commit/9d76c7c60ff3133c1078892d7c50a2cfc9ff9c1b

8340418: GHA: MacOS AArch64 bundles can be removed prematurely

Reviewed-by: erikj

! .github/workflows/main.yml

Changeset: 5d611c03
Branch: hermetic-java-runtime
Author:    SendaoYan <syan at openjdk.org>
Committer: Hamlin Li <mli at openjdk.org>
Date:      2024-09-20 07:34:26 +0000
URL:       https://git.openjdk.org/leyden/commit/5d611c0377d4b5d5495d3941a6a63b128142a2dc

8340439: AArch64: Extra entry declaration for assember test

Reviewed-by: haosun, lmesnik, mli

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

Changeset: a50440fa
Branch: hermetic-java-runtime
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-20 09:21:12 +0000
URL:       https://git.openjdk.org/leyden/commit/a50440fadcd1aa9d8bfddc153dbde6fd55ceb9fa

8340456: Reduce overhead of proxying Object methods in ProxyGenerator

Reviewed-by: liach

! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
- test/micro/org/openjdk/bench/java/lang/reflect/Proxy/ProxyPerf.java
= test/micro/org/openjdk/bench/java/lang/reflect/proxy/ProxyBench.java
+ test/micro/org/openjdk/bench/java/lang/reflect/proxy/ProxyGeneratorBench.java

Changeset: 3ad6e31d
Branch: hermetic-java-runtime
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-09-20 09:33:31 +0000
URL:       https://git.openjdk.org/leyden/commit/3ad6e31d81bb8a47dc73a6342a6524a901f07687

8340438: RISC-V: minor improvement in base64

Reviewed-by: fyang

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

Changeset: 3c22d83c
Branch: hermetic-java-runtime
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-09-20 10:07:03 +0000
URL:       https://git.openjdk.org/leyden/commit/3c22d83c0fb9eee2e2b87e607680b96363849c16

8340008: KeyEvent/KeyTyped/Numpad1KeyTyped.java has 15 seconds timeout

Reviewed-by: azvegint, prr

+ test/jdk/java/awt/event/KeyEvent/KeyTyped/Numpad1KeyTyped.java

Changeset: fe80618b
Branch: hermetic-java-runtime
Author:    Andrey Turbanov <aturbanov at openjdk.org>
Date:      2024-09-20 12:43:57 +0000
URL:       https://git.openjdk.org/leyden/commit/fe80618bf3f80094a93239dd43d4a9b515c5fa18

8339972: Make a few fields in SortingFocusTraversalPolicy static

Reviewed-by: azvegint, aivanov

! src/java.desktop/share/classes/javax/swing/SortingFocusTraversalPolicy.java

Changeset: ae63aaaa
Branch: hermetic-java-runtime
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-09-20 14:10:39 +0000
URL:       https://git.openjdk.org/leyden/commit/ae63aaaa5847a68542e1483ecf1f0d5a3704e741

8340540: Problemlist DcmdMBeanPermissionsTest.java and SystemDumpMapTest.java

Reviewed-by: kevinw

! test/hotspot/jtreg/ProblemList.txt
! test/jdk/ProblemList.txt

Changeset: 9bcde4ff
Branch: hermetic-java-runtime
Author:    Amit Kumar <amitkumar at openjdk.org>
Date:      2024-09-20 14:46:10 +0000
URL:       https://git.openjdk.org/leyden/commit/9bcde4ffca20941b010ed454b2fcb948d24b3cac

8338658: New Object to ObjectMonitor mapping: s390x implementation

Reviewed-by: lucy, mdoerr

! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
! src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp
! src/hotspot/cpu/s390/interp_masm_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.hpp
! src/hotspot/cpu/s390/sharedRuntime_s390.cpp
! src/hotspot/share/runtime/basicLock.inline.hpp

Changeset: e087edeb
Branch: hermetic-java-runtime
Author:    Amit Kumar <amitkumar at openjdk.org>
Date:      2024-09-20 14:48:11 +0000
URL:       https://git.openjdk.org/leyden/commit/e087edeb256a9743d1fdb6c295cb5add78d4552e

8340269: [s390x] TestLargeStub.java failure after 8338123

Reviewed-by: mdoerr, lucy

! src/hotspot/cpu/s390/downcallLinker_s390.cpp

Changeset: 90d3a64b
Branch: hermetic-java-runtime
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-20 16:02:25 +0000
URL:       https://git.openjdk.org/leyden/commit/90d3a64b0afd5810981287b174c6687f0f604f36

8340537: Typo in javadoc of java.util.jar.JarFile

Reviewed-by: mullan, lancea, iris

! src/java.base/share/classes/java/util/jar/JarFile.java

Changeset: ab81197d
Branch: hermetic-java-runtime
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-20 16:11:39 +0000
URL:       https://git.openjdk.org/leyden/commit/ab81197d0ded93b82eea9f8fb35d1647c4520f1e

8339198: Remove tag field from AbstractPoolEntry

Reviewed-by: asotona, redestad

! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java

Changeset: 40fba148
Branch: hermetic-java-runtime
Author:    Shaojin Wen <swen at openjdk.org>
Date:      2024-09-20 17:54:06 +0000
URL:       https://git.openjdk.org/leyden/commit/40fba148125b9e0d35755b6e6fd701e69d22f7da

8340232: Optimize DataInputStream::readUTF

Reviewed-by: liach, bpb

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

Changeset: 5cffddc6
Branch: hermetic-java-runtime
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-09-20 18:38:29 +0000
URL:       https://git.openjdk.org/leyden/commit/5cffddc689a0134e1aaacb432d2f0fdd61dd74b1

8338471: Assert deleted methods not returned by CallInfo

Reviewed-by: shade, jwaters, dholmes

! src/hotspot/share/code/compiledIC.cpp
! src/hotspot/share/interpreter/linkResolver.cpp
! src/hotspot/share/interpreter/linkResolver.hpp
! src/hotspot/share/oops/cpCache.cpp

Changeset: 64275e6b
Branch: hermetic-java-runtime
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2024-09-20 19:34:24 +0000
URL:       https://git.openjdk.org/leyden/commit/64275e6bbf1377c9a9d77fe3c3ed8d4143138f11

8340092: [Linux] containers/systemd/SystemdMemoryAwarenessTest.java failing on some systems

Reviewed-by: mbaesken

= test/hotspot/jtreg/containers/systemd/TEST.properties
! test/lib/jdk/test/lib/containers/systemd/SystemdTestUtils.java

Changeset: 08b25611
Branch: hermetic-java-runtime
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-09-20 21:27:22 +0000
URL:       https://git.openjdk.org/leyden/commit/08b25611f688ae85c05242afc4cee5b538db4f67

8339781: Better use of Javadoc tags in javax.lang.model

Reviewed-by: jjg

! src/java.compiler/share/classes/javax/annotation/processing/Processor.java
! src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java
! src/java.compiler/share/classes/javax/lang/model/element/NestingKind.java
! src/java.compiler/share/classes/javax/lang/model/util/Types.java

Changeset: 2461263a
Branch: hermetic-java-runtime
Author:    Shaojin Wen <swen at openjdk.org>
Date:      2024-09-21 00:21:04 +0000
URL:       https://git.openjdk.org/leyden/commit/2461263aac35b25e2a48b6fc84da49e4b553dbc3

8339217: Optimize ClassFile API loadConstant

Reviewed-by: liach, redestad, asotona

! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java

Changeset: ab06a878
Branch: hermetic-java-runtime
Author:    Shaojin Wen <swen at openjdk.org>
Date:      2024-09-22 01:01:31 +0000
URL:       https://git.openjdk.org/leyden/commit/ab06a878f888827026424530781f0af414a8a611

8340544: Optimize setLocalsFromArg

Reviewed-by: redestad, liach

! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java

Changeset: dd498794
Branch: hermetic-java-runtime
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-09-23 05:48:42 +0000
URL:       https://git.openjdk.org/leyden/commit/dd498794f20df0ac1a73d84e54591905c8a5a5c7

8340524: Remove NarrowPtrStruct

Reviewed-by: shade, jwaters

! src/hotspot/share/oops/compressedOops.cpp
! src/hotspot/share/oops/compressedOops.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/CompressedOops.java

Changeset: 34cddfbe
Branch: hermetic-java-runtime
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-09-23 06:40:33 +0000
URL:       https://git.openjdk.org/leyden/commit/34cddfbedd20d5804cab8044fbc402564e98eb9c

8340387: Update OS detection code to recognize Windows Server 2025

Reviewed-by: mdoerr, jwaters, dholmes

! src/hotspot/os/windows/os_windows.cpp
! src/java.base/windows/native/libjava/java_props_md.c

Changeset: f31f97dd
Branch: hermetic-java-runtime
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-23 07:02:48 +0000
URL:       https://git.openjdk.org/leyden/commit/f31f97ddb6f1fca1a74761e3e3eeef497f8a7416

8340171: CDS: Enhance bitmap truncation

Reviewed-by: matsaave, iklam

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

Changeset: 0f253d11
Branch: hermetic-java-runtime
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-23 07:02:59 +0000
URL:       https://git.openjdk.org/leyden/commit/0f253d11033a26d15ea20df19db6765bb274a848

8340392: Handle OopStorage in location decoder

Reviewed-by: kbarrett, dholmes

! src/hotspot/share/gc/shared/oopStorage.cpp
! src/hotspot/share/gc/shared/oopStorage.hpp
! src/hotspot/share/gc/shared/oopStorage.inline.hpp
! src/hotspot/share/gc/shared/oopStorageSet.cpp
! src/hotspot/share/gc/shared/oopStorageSet.hpp
! src/hotspot/share/runtime/os.cpp
! test/hotspot/gtest/gc/shared/test_oopStorageSet.cpp

Changeset: a07052e8
Branch: hermetic-java-runtime
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-09-23 08:02:16 +0000
URL:       https://git.openjdk.org/leyden/commit/a07052e83d20e107f21fd0d266ab638043531c8a

8340573: Remove unused G1ParScanThreadState::_partial_objarray_chunk_size

Reviewed-by: tschatzl

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

Changeset: bc7c0dc4
Branch: hermetic-java-runtime
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Date:      2024-09-23 08:02:36 +0000
URL:       https://git.openjdk.org/leyden/commit/bc7c0dc45dcd66d24ece8ebbd5c1b25e131eae67

8340084: Open source AWT Frame related tests

Reviewed-by: psadhukhan, honkar

+ test/jdk/java/awt/Frame/DefaultLocationTest.java
+ test/jdk/java/awt/Frame/EmptyFrameTest.java
+ test/jdk/java/awt/Frame/FrameLayoutTest.java
+ test/jdk/java/awt/Frame/FrameSetMinimumSizeTest.java
+ test/jdk/java/awt/Frame/PackTwiceTest.java

Changeset: 67448b0e
Branch: hermetic-java-runtime
Author:    Pavel Rappo <prappo at openjdk.org>
Date:      2024-09-23 10:32:58 +0000
URL:       https://git.openjdk.org/leyden/commit/67448b0eb2e83501b9c1dd0c79c7fe03aaef6b09

8339852: Fix typos in java.compiler documentation

Reviewed-by: liach, darcy

! src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java
! src/java.compiler/share/classes/javax/annotation/processing/RoundEnvironment.java
! src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java
! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
! src/java.compiler/share/classes/javax/lang/model/element/AnnotationMirror.java
! src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java
! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java
! src/java.compiler/share/classes/javax/lang/model/element/package-info.java
! src/java.compiler/share/classes/javax/lang/model/util/Elements.java
! src/java.compiler/share/classes/javax/lang/model/util/Types.java
! src/java.compiler/share/classes/javax/tools/ForwardingFileObject.java
! src/java.compiler/share/classes/javax/tools/ForwardingJavaFileManager.java
! src/java.compiler/share/classes/javax/tools/ForwardingJavaFileObject.java
! src/java.compiler/share/classes/javax/tools/JavaFileManager.java
! src/java.compiler/share/classes/javax/tools/StandardJavaFileManager.java
! src/java.compiler/share/classes/javax/tools/ToolProvider.java

Changeset: 384deda6
Branch: hermetic-java-runtime
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-09-23 10:57:43 +0000
URL:       https://git.openjdk.org/leyden/commit/384deda65fd63e23d4caaaa9762f2ac80de78029

8325949: Create an internal utility method for creating VarHandle instances

Reviewed-by: rriggs

! src/java.base/share/classes/java/lang/ThreadBuilders.java
! src/java.base/share/classes/java/lang/invoke/Invokers.java
! src/java.base/share/classes/java/net/Socket.java
! src/java.base/share/classes/java/nio/channels/SelectionKey.java
! src/java.base/share/classes/java/nio/channels/spi/AbstractSelectionKey.java
! src/java.base/share/classes/java/nio/channels/spi/AbstractSelector.java
! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java
! src/java.base/share/classes/java/util/concurrent/Exchanger.java
! src/java.base/share/classes/java/util/concurrent/FutureTask.java
! src/java.base/share/classes/java/util/concurrent/Phaser.java
! src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java
! src/java.base/share/classes/java/util/concurrent/SubmissionPublisher.java
! src/java.base/share/classes/java/util/concurrent/ThreadPerTaskExecutor.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicBoolean.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicMarkableReference.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReference.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java
! src/java.base/share/classes/java/util/concurrent/atomic/Striped64.java
! src/java.base/share/classes/java/util/stream/ForEachOps.java
! src/java.base/share/classes/java/util/stream/GathererOp.java
! src/java.base/share/classes/jdk/internal/foreign/ConfinedSession.java
! src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java
! src/java.base/share/classes/jdk/internal/foreign/SharedSession.java
! src/java.base/share/classes/jdk/internal/foreign/abi/DowncallLinker.java
! src/java.base/share/classes/jdk/internal/foreign/layout/AbstractLayout.java
+ src/java.base/share/classes/jdk/internal/invoke/MhUtil.java
! src/java.base/share/classes/jdk/internal/misc/ThreadFlock.java
! src/java.base/share/classes/jdk/internal/reflect/DirectMethodHandleAccessor.java
! src/java.base/share/classes/jdk/internal/vm/SharedThreadContainer.java
! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java

Changeset: 37ec80df
Branch: hermetic-java-runtime
Author:    Joel Sikstr?m <joel.sikstrom at oracle.com>
Committer: Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-23 12:28:43 +0000
URL:       https://git.openjdk.org/leyden/commit/37ec80df8d3b014292fc3d31a1b2aad4e8218ea5

8339161: ZGC: Remove unused remembered sets

Reviewed-by: aboldtch, stefank

! src/hotspot/share/gc/z/zHeap.cpp
! src/hotspot/share/gc/z/zPage.cpp
! src/hotspot/share/gc/z/zPage.hpp
! src/hotspot/share/gc/z/zPageAllocator.cpp
! src/hotspot/share/gc/z/zRelocate.cpp
! src/hotspot/share/gc/z/zRememberedSet.cpp
! src/hotspot/share/gc/z/zRememberedSet.hpp

Changeset: 63e611cd
Branch: hermetic-java-runtime
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2024-09-23 12:30:30 +0000
URL:       https://git.openjdk.org/leyden/commit/63e611cd5d7eb4fc6ea6633ff9123e4bee5f5993

8335334: Stress mode to randomly execute unstable if traps

Reviewed-by: chagedorn, kvn

! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/cfgnode.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/ifnode.cpp
! src/hotspot/share/opto/parse.hpp
! src/hotspot/share/opto/parse2.cpp
! test/hotspot/jtreg/compiler/arguments/TestStressOptions.java
! test/hotspot/jtreg/compiler/c2/irTests/TestPrunedExHandler.java
! test/hotspot/jtreg/compiler/cha/StrengthReduceInterfaceCall.java
! test/hotspot/jtreg/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java
! test/hotspot/jtreg/compiler/rangechecks/TestExplicitRangeChecks.java
! test/hotspot/jtreg/compiler/uncommontrap/TestUnstableIfTrap.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicBooleanOpTest.java
! test/hotspot/jtreg/compiler/whitebox/DeoptimizeFramesTest.java
! test/jdk/jdk/jfr/event/compiler/TestDeoptimization.java

Changeset: a9b0f9cc
Branch: hermetic-java-runtime
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
Date:      2024-09-23 13:58:00 +0000
URL:       https://git.openjdk.org/leyden/commit/a9b0f9ccbf98c6b90626fcd7087fa8eeb0c168eb

8340393: Open source closed choice tests #2

Reviewed-by: psadhukhan

+ test/jdk/java/awt/Choice/CheckChoiceTest.java
+ test/jdk/java/awt/Choice/ChoiceBigTest.java
+ test/jdk/java/awt/Choice/ChoiceFocusTest.java
+ test/jdk/java/awt/Choice/DisabledList.java

Changeset: ea8f35b9
Branch: hermetic-java-runtime
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-23 14:33:17 +0000
URL:       https://git.openjdk.org/leyden/commit/ea8f35b98e618bfa55371e45b3ef61fa5289dd94

8340183: Shenandoah: Incorrect match for clone barrier in is_gc_barrier_node

Reviewed-by: roland, rkennke

! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.hpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp

Changeset: 0f9f7775
Branch: hermetic-java-runtime
Author:    Lance Andersen <lancea at openjdk.org>
Date:      2024-09-23 16:07:12 +0000
URL:       https://git.openjdk.org/leyden/commit/0f9f777520c5341be1e9f985f41304a297b08936

8336025: Improve ZipOutputSream validation of MAX CEN Header field limits

Reviewed-by: alanb

! src/java.base/share/classes/java/util/zip/ZipEntry.java
! src/java.base/share/classes/java/util/zip/ZipOutputStream.java
! test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java
+ test/jdk/java/util/zip/ZipOutputStream/ZipOutputStreamMaxCenHdrTest.java

Changeset: b359f0cc
Branch: hermetic-java-runtime
Author:    Jiangli Zhou <jianglizhou at google.com>
Date:      2024-09-24 17:55:28 +0000
URL:       https://git.openjdk.org/leyden/commit/b359f0ccc68ef623e349389b7f3ac376584b0932

Merge commit '0f9f777520c5341be1e9f985f41304a297b08936' into hermetic-java-runtime

! make/Main.gmk
! make/autoconf/spec.gmk.template
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! src/hotspot/share/runtime/threads.cpp
! src/hotspot/share/utilities/globalDefinitions.hpp
! src/java.base/share/native/libjli/java.c
! make/Main.gmk
! make/autoconf/spec.gmk.template
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! src/hotspot/share/runtime/threads.cpp
! src/hotspot/share/utilities/globalDefinitions.hpp
! src/java.base/share/native/libjli/java.c


From asmehra at redhat.com  Wed Sep 25 01:36:44 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Tue, 24 Sep 2024 21:36:44 -0400
Subject: [External] : Re: premain: Crash in Infinispan server code caused
 by NPE under MethodHandleNative::linkDynamicConstant
In-Reply-To: <199d99cb-5e4c-40c6-a9b5-3e5e456f1968@oracle.com>
References: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
 <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>
 <CAKt0pySztvwsadtrqjai6XwakAWq_v_o8men4aopLo4X-0azyQ@mail.gmail.com>
 <CAKt0pyQ44E+npyUW35Zhxg+PfBgF2yuNgS61gj1GGj=aLGTJXw@mail.gmail.com>
 <CAKt0pyT48uPH6rUL7bEJ2rtWqNdNL34DWBJ2SDaHwYfVxURnQw@mail.gmail.com>
 <0d22d580-39a1-4105-a50e-8a74a555090d@oracle.com>
 <CAKt0pyRYBNtkLzVoAfDHWE=4e+9efZFb+xKYZv-d3LpDAU4qZg@mail.gmail.com>
 <da797fe2-137c-4fc7-a67c-3b595c0c63f2@oracle.com>
 <CAKt0pyRj8_mDiH58v10sqXNHA4iHja6-7D9N_S2VW9rhESPcTw@mail.gmail.com>
 <45e62b78-bbde-4ba5-8b20-77125d14b908@oracle.com>
 <4dc70b95-f014-44f1-acfb-027c8e28e81d@oracle.com>
 <CAKt0pyQ8T+-yZQ1UJBewcc_DXTMRymNRSp3cz4xCZf54XUhw+g@mail.gmail.com>
 <9ec705a7-4fa5-40f8-8685-b49c54ab4418@oracle.com>
 <CAKt0pyTQXoW82Dx=BRFx93_wm6dEiCcncT66mDOHGXt4GqiE0Q@mail.gmail.com>
 <199d99cb-5e4c-40c6-a9b5-3e5e456f1968@oracle.com>
Message-ID: <CAKt0pyTixr_fwL-f+=zuRv38a2=3tXHRct2tVAVLvgrp7jVYhg@mail.gmail.com>

>
> I disabled the AOTClassInitializer::is_forced_preinit_class() call and
> synced AOTClassInitializer::can_archive_preinitialized_mirror() with my
> upstream PR. This seems to fix the error in your test case.
>

I verified that this change fixes the error in the testcase. Thanks for
fixing this issue.

- Ashutosh Mehra


On Tue, Sep 24, 2024 at 1:01?PM <ioi.lam at oracle.com> wrote:

> Hi Ashutosh,
>
> I disabled the AOTClassInitializer::is_forced_preinit_class() call and
> synced AOTClassInitializer::can_archive_preinitialized_mirror() with my
> upstream PR. This seems to fix the error in your test case.
>
> Could you give it a try?
>
>
> https://github.com/iklam/jdk/commit/df72d0ba8dc799767521c939a531c4128e58c636
>
> Thanks
>
> - Ioi
>
>
>
> https://github.com/iklam/jdk/commit/df72d0ba8dc799767521c939a531c4128e58c636
> On 9/24/24 8:24 AM, Ashutosh Mehra wrote:
>
> Hi Ioi,
> Thanks for sharing the code changes.
> The wildfly-elytron testcase passes with these changes, but I still get
> the NPE in PrimitiveClassDescImpl.<clinit> when running with my own
> testcase.
> I have pushed my test case to a repo [2], so you can try it as well. I
> have added some instructions to the Readme file.
> Let me know if you face any issues in running the test case.
>
> [2] https://github.com/ashu-mehra/leyden-testcase/
> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden-testcase/__;!!ACWV5N9M2RV99hQ!JiRlHQ7c-vdXVJoc61a64CilNOg5VTLitO8JELhohSZdibAXZUEjeA38WbtygjLvPsQIQKUYXJ2_kA$>
>
> Thanks,
> - Ashutosh Mehra
>
>
> On Mon, Sep 23, 2024 at 11:24?PM <ioi.lam at oracle.com> wrote:
>
>> Hi Ashutosh,
>>
>> Thank you again for the summary of the issues.
>> I looked at the call paths again and I think two calls need to be moved
>>
>> (1) MethodType::createArchivedObjects() needs to be called after we have
>> executed all other Java code. So I put it before the
>> StringTable::allocate_shared_strings_array() call.
>>
>> (2) SystemDictionary::get_all_method_handle_intrinsics() needs to be done
>> inside the safepoint, so it can be sure to find all the method handle
>> intrinsic methods (which can be generated as the side effect of Java code
>> execution).
>>
>> I also added the archiving of the classData field.
>>
>> See my temporary change at
>> https://github.com/iklam/jdk/commit/eafaa9731ae89b93f3e20702fc4d5a12cb070149
>> <https://urldefense.com/v3/__https://github.com/iklam/jdk/commit/eafaa9731ae89b93f3e20702fc4d5a12cb070149__;!!ACWV5N9M2RV99hQ!JiRlHQ7c-vdXVJoc61a64CilNOg5VTLitO8JELhohSZdibAXZUEjeA38WbtygjLvPsQIQKXvE8zr1g$>
>>
>> With this change, I am able to successfully run the test in
>> https://github.com/tristantarrant/elytron-leyden
>> <https://urldefense.com/v3/__https://github.com/tristantarrant/elytron-leyden__;!!ACWV5N9M2RV99hQ!JiRlHQ7c-vdXVJoc61a64CilNOg5VTLitO8JELhohSZdibAXZUEjeA38WbtygjLvPsQIQKW7YFmGjQ$>
>> . I also modified the LambdaWithUseImplMethodHandle.java test to add a
>> similar test scenario.
>>
>> I agree with you that the code in
>> AOTClassInitializer::is_forced_preinit_class() is too ad-hoc, and might
>> change the order of class initialization. In the upstream PR, I have
>> changed the code to only assert that the listed of classes has been
>> initialized:
>>
>>
>> https://github.com/iklam/jdk/blob/5cc31ed60cc9597d63b86f20b95c964d4d1a6b84/src/hotspot/share/cds/aotClassInitializer.cpp#L66-L84
>> <https://urldefense.com/v3/__https://github.com/iklam/jdk/blob/5cc31ed60cc9597d63b86f20b95c964d4d1a6b84/src/hotspot/share/cds/aotClassInitializer.cpp*L66-L84__;Iw!!ACWV5N9M2RV99hQ!JiRlHQ7c-vdXVJoc61a64CilNOg5VTLitO8JELhohSZdibAXZUEjeA38WbtygjLvPsQIQKUJSR9oEw$>
>>
>> I will try to merge this version of the code back to the Leyden repo.
>>
>> I think by doing this, we can avoid direct manipulation of the class-init
>> order of the core-library classes. Instead, we just make sure that we
>> execute enough "normal" code during the assembly phase to ensure that these
>> classes are initialized in their normal order.
>>
>> What do you think?
>>
>> Thanks
>>
>> - Ioi
>>
>>
>> On 9/19/24 8:05 PM, Ashutosh Mehra wrote:
>>
>> Upon further investigation, it seems a simple patch might fix the problem
>>> with classData.
>>>
>>> I tested with
>>> test/hotspot/jtreg/runtime/cds/appcds/LambdaWithUseImplMethodHandle.java by
>>> running jtreg with -javaoptions:-XX:+AOTClassLinking
>>> Without the patch, I'd get a NullPointerException. With the patch, the
>>> test passes.
>>>
>>> It looks like classData is not treated as a static field of the class,
>>> but rather an instance field in the mirror. So classData wasn't copied by
>>> the loop in HeapShared::copy_preinitialized_mirror().
>>>
>>> Ashutosh, could you try it this fixes the crash on your side?
>>>
>>> Thanks
>>>
>>> - Ioi
>>>
>>> diff --git a/src/hotspot/share/cds/heapShared.cpp
>>> b/src/hotspot/share/cds/heapShared.cpp
>>> index 0e70778f057..62cf142f67a 100644
>>> --- a/src/hotspot/share/cds/heapShared.cpp
>>> +++ b/src/hotspot/share/cds/heapShared.cpp
>>> @@ -634,6 +634,8 @@ void HeapShared::copy_preinitialized_mirror(Klass*
>>> orig_k, oop orig_mirror, oop
>>>      }
>>>    }
>>>
>>> +  java_lang_Class::set_class_data(m,
>>> java_lang_Class::class_data(orig_mirror));
>>> +
>>>    // Class::reflectData use SoftReference, which cannot be archived.
>>> Set it
>>>    // to null and it will be recreated at runtime.
>>>    java_lang_Class::set_reflection_data(m, nullptr);
>>>
>>
>> Hi Ioi,
>>
>> This patch effectively does the same thing as my initial patch for
>> storing classData in the scratch mirror object [1].
>>
>> At this point I think it would be useful to do a quick recap of the
>> issues mentioned in this thread. There are 3 issues I have encountered so
>> far.
>> I was initially thinking of a solution that would cover all these
>> problems, but looking at these again, I feel these are orthogonal to each
>> other:
>>
>> 1. The missing classData in scratch mirrors which can be fixed by either
>> of the patches shared in this thread. They achieve the same goal and I
>> don't have any strong preference for any of them.
>>
>> 2. After fixing the classData, I ran into  WrongMethodTypeException issue
>> [2] which I fixed by exchanging the order of indy resolution with the call
>> to MethodType::createArchivedObjects [3].
>> This change makes sense because we want to make sure all the MethodType
>> objects that can be archived are in MethodType internTable before calling
>> MethodType::createArchivedObjects.
>> I am not sure why LambdaWithUseImplMethodHandle.java didn't throw the
>> WrongMethodTypeException, as the Infinispan code does.
>>
>> 3. After fixing the WrongMethodTypeException I hit NPE due to the class
>> initialization cycle between PrimitiveClassDescImpl and ConstantDescs [4]
>> in one of my own testcase.
>> We are looking for a solution to this problem. I am not sure if we can
>> break this cycle by refactoring the Java code.
>> Nevertheless, I think it is fair to assume that there is no Java code
>> that can initiate initialization of PrimitiveClassDescImpl before
>> ConstantDescs, otherwise we would have hit the NPE earlier.
>> So if ConstantDescs is always expected to be initialized before
>> PrimitiveClassDescImpl then I think the VM code should also maintain
>> this assumption.
>> Now this brings us back to the forceful initialization done by the VM
>> during the assembly phase based on the forced_preinit_classes list in
>> aotClassInitializer.cpp:
>>
>>     // TODO:
>>     // This is needed since JDK-8338532. Without this, when
>>     // archived heap objects are used, the class init order is not
>>     // expected by the jdk/internal/constant bootstrap code and we
>>     // will get a null pointer exception.
>>     //
>>     // When bootstraping has intricated/fragile order, it's probably
>>     // better to archive all related classes in an initialized state
>>     // (i.e., take a snapshot). The existing approach in
>>     // heapShared::resolve_or_init_classes_for_subgraph_of() won't work.
>>     "jdk/internal/constant/PrimitiveClassDescImpl",
>>     "jdk/internal/constant/ReferenceClassDescImpl",
>>     "java/lang/constant/ConstantDescs",
>>     "sun/invoke/util/Wrapper",
>>
>> I wonder why we need to explicitly add  PrimitiveClassDescImpl and
>> ReferenceClassDescImpl in this list.
>> Initialization of ConstantDescs would anyway trigger the initialization
>> of PrimitiveClassDescImpl and ReferenceClassDescImpl.
>> So if we only keep the entry for ConstantDescs and remove
>> PrimitiveClassDescImpl and ReferenceClassDescImpl from this list,
>> we can be sure that the forceful initialization by the VM would maintain
>> the same order of initialization as guided by the Java code,
>> and we will not hit the NPE when initializing PrimitiveClassDescImpl during
>> the assembly phase.
>> Does this make sense?
>>
>>
>> [1]
>> https://mail.openjdk.org/pipermail/leyden-dev/2024-September/000994.html
>> [2]
>> https://mail.openjdk.org/pipermail/leyden-dev/2024-September/000997.html
>> [3]
>> https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!KvYLs_vG0a4GO3ltinXQkxBG1kMhCAvmmM6MwODoKzOhhVjzNL80S_0mBzYvYyhYPQnGmXhAXSw78Q$>
>> [4]
>> https://mail.openjdk.org/pipermail/leyden-dev/2024-September/001018.html
>>
>> Thanks,
>> - Ashutosh Mehra
>>
>>
>> On Thu, Sep 19, 2024 at 8:51?PM <ioi.lam at oracle.com> wrote:
>>
>>> Upon further investigation, it seems a simple patch might fix the
>>> problem with classData.
>>>
>>> I tested with
>>> test/hotspot/jtreg/runtime/cds/appcds/LambdaWithUseImplMethodHandle.java by
>>> running jtreg with -javaoptions:-XX:+AOTClassLinking
>>> Without the patch, I'd get a NullPointerException. With the patch, the
>>> test passes.
>>>
>>> It looks like classData is not treated as a static field of the class,
>>> but rather an instance field in the mirror. So classData wasn't copied by
>>> the loop in HeapShared::copy_preinitialized_mirror().
>>>
>>> Ashutosh, could you try it this fixes the crash on your side?
>>>
>>> Thanks
>>>
>>> - Ioi
>>>
>>> diff --git a/src/hotspot/share/cds/heapShared.cpp
>>> b/src/hotspot/share/cds/heapShared.cpp
>>> index 0e70778f057..62cf142f67a 100644
>>> --- a/src/hotspot/share/cds/heapShared.cpp
>>> +++ b/src/hotspot/share/cds/heapShared.cpp
>>> @@ -634,6 +634,8 @@ void HeapShared::copy_preinitialized_mirror(Klass*
>>> orig_k, oop orig_mirror, oop
>>>      }
>>>    }
>>>
>>> +  java_lang_Class::set_class_data(m,
>>> java_lang_Class::class_data(orig_mirror));
>>> +
>>>    // Class::reflectData use SoftReference, which cannot be archived.
>>> Set it
>>>    // to null and it will be recreated at runtime.
>>>    java_lang_Class::set_reflection_data(m, nullptr);
>>>
>>>
>>>
>>> On 9/19/24 12:51 PM, ioi.lam at oracle.com wrote:
>>>
>>>
>>> On 9/19/24 7:44 AM, Ashutosh Mehra wrote:
>>>
>>> As I am cleaning up the code for upstreaming to mainline, I am going add
>>>> an equivalent check in the C code to filter out these indy call sites, so
>>>> they won't be resolved at all during the assembly phase. Otherwise, I will
>>>> run into problems described in
>>>> https://bugs.openjdk.org/browse/JDK-8290417
>>>
>>>
>>> Thanks for the link to the bug. The scenario described in that bug is
>>> exactly the same as the Infinispan case.
>>> So if we filter out such cases during indy resolution then it should
>>> resolve the Infinispan issue as well.
>>>
>>> A basic question: why can't CDS handle the lambda proxy class generated
>>> in useImplMethodHandle mode?
>>>
>>> If I remember correctly, it has to do with the shape of dynamically
>>> generated bytecode:
>>>
>>>   public void accept(java.lang.Object);
>>>     Code:
>>>        0: ldc #28 // Dynamic #0:_:Ljava/lang/invoke/MethodHandle;
>>>        2: aload_0
>>>        3: getfield #15 // Field arg$1:LTester;
>>>        6: aload_1
>>>        7: checkcast #30 // class java/lang/String
>>>       10: invokevirtual #36 // Method
>>> java/lang/invoke/MethodHandle.invokeExact:(LTester;Ljava/lang/String;)V
>>>       13: return
>>>
>>> The result of the "ldc" was not symbolically encoded in the generated
>>> class (as the generated class has no permission to access that method). So
>>> the MethodHandle is stored as a binary object in the mirror of this
>>> generated class (with the java.lang.Class::classData field).
>>>
>>> Plain CDS doesn't archive class mirrors, so the classData will be lost.
>>>
>>> With JEP 483, we should be able to preserve the classData, so I am not
>>> sure why the useImplMethodHandle case is still failing. My plan is to
>>> filter these out for now, but I will get back to it later when I have more
>>> time.
>>>
>>> Thanks
>>>
>>> - Ioi
>>>
>>>
>>>
>>> Thanks,
>>> - Ashutosh Mehra
>>>
>>>
>>> On Thu, Sep 19, 2024 at 1:45?AM <ioi.lam at oracle.com> wrote:
>>>
>>>> Hi Ashutosh,
>>>>
>>>> I have some update:
>>>>
>>>> The original crash was caused by the "useImplMethodHandle" code in
>>>> InnerClassLambdaMetafactory.java:
>>>>
>>>>         // If the target class invokes a protected method inherited
>>>> from a
>>>>         // superclass in a different package, or does 'invokespecial',
>>>> the
>>>>         // lambda class has no access to the resolved method, or does
>>>>         // 'invokestatic' on a hidden class which cannot be resolved by
>>>> name.
>>>>         // Instead, we need to pass the live implementation method
>>>> handle to
>>>>         // the proxy class to invoke directly. (javac prefers to avoid
>>>> this
>>>>         // situation by generating bridges in the target class)
>>>>         useImplMethodHandle =
>>>> (Modifier.isProtected(implInfo.getModifiers()) &&
>>>>                                !VerifyAccess.isSamePackage(targetClass,
>>>> implInfo.getDeclaringClass())) ||
>>>>                                implKind ==
>>>> MethodHandleInfo.REF_invokeSpecial ||
>>>>                                implKind ==
>>>> MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>>>>
>>>> As I am cleaning up the code for upstreaming to mainline, I am going
>>>> add an equivalent check in the C code to filter out these indy call sites,
>>>> so they won't be resolved at all during the assembly phase. Otherwise, I
>>>> will run into problems described in
>>>> https://bugs.openjdk.org/browse/JDK-8290417
>>>>
>>>> Once I get the filtering code working, I will integrate it back to
>>>> premain.
>>>>
>>>> >I am wondering if we can workaround class circularity issues by
>>>> recording class initialization order
>>>> >during training run and use that to guide the initialization during
>>>> assembly phase.
>>>>
>>>> In the production run we take different paths than the training run
>>>>
>>>> (1) some classes are aot-initialized (especially the enums)
>>>> (2) some classes make special CDS calls
>>>>
>>>> so I am not sure if it's possible to get the same initialization order
>>>> as in the training run (or assembly phase).
>>>>
>>>> (more below)
>>>> On 9/18/24 9:10 AM, Ashutosh Mehra wrote:
>>>>
>>>> Hi Ioi,
>>>>
>>>> I was having a similar circularity issue (but in production time) and I
>>>>> just added enough classes to make the NPE go away.
>>>>>
>>>>
>>>> I am wondering if you have a test case that reproduces the NPE which
>>>> prompted you to add these classes:
>>>>
>>>>
>>>> https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp#L65-L78
>>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp*L65-L78__;Iw!!ACWV5N9M2RV99hQ!NYvqLbb_Ib2kSdm2fcYVLGby-AiB2TG7KtC1HQHVKLiM-_kRb5mOt8krV5IZfReaYZ0MPadDfa08hQ$>
>>>>
>>>> I commented this code and ran the tests under premain but didn't
>>>> hit the NPE.
>>>>
>>>> I forgot what the problem was, but it happened for very simple cases.
>>>>
>>>> Thanks
>>>>
>>>> - Ioi
>>>>
>>>>
>>>> Thanks,
>>>> - Ashutosh Mehra
>>>>
>>>>
>>>> On Tue, Sep 17, 2024 at 1:11?AM <ioi.lam at oracle.com> wrote:
>>>>
>>>>> Hi Ashutosh,
>>>>>
>>>>> So this looks like a potential bug (or feature) in the core lib code.
>>>>> When CDS forcefully initializes a class in an unexpected (or untested)
>>>>> order, the "initialization soup" fails.
>>>>>
>>>>> Perhaps a work-around would be to make some harmless calls at the
>>>>> place where CDS was calling into MethodType.createArchivedObjects(). E.g.,
>>>>> do something like this:
>>>>>
>>>>> +    if (CDSConfig::is_dumping_invokedynamic()) {
>>>>> +       // call into Java: jdk.internal.misc::warmupInvokeDynamic();
>>>>> +   }
>>>>>     // Rewrite and link classes
>>>>>     log_info(cds)("Rewriting and linking classes ...");
>>>>>
>>>>> Maybe you can add a new Lambda expressions, MethodHandle invocations,
>>>>> etc, that would hopefully cause PrimitiveClassDescImpl and friends to be
>>>>> initialized in their natural order.
>>>>>
>>>>> Or call class.forName("java.lang.constant.ConstantDescs") ??
>>>>>
>>>>> BTW, you can see my comments in
>>>>> AOTClassInitializer::is_forced_preinit_class():
>>>>>
>>>>>     // TODO:
>>>>>     // This is needed since JDK-8338532. Without this, when
>>>>>     // archived heap objects are used, the class init order is not
>>>>>     // expected by the jdk/internal/constant bootstrap code and we
>>>>>     // will get a null pointer exception.
>>>>>     //
>>>>>     // When bootstraping has intricated/fragile order, it's probably
>>>>>     // better to archive all related classes in an initialized state
>>>>>     // (i.e., take a snapshot). The existing approach in
>>>>>     // heapShared::resolve_or_init_classes_for_subgraph_of() won't
>>>>> work.
>>>>>     "jdk/internal/constant/PrimitiveClassDescImpl",
>>>>>     "jdk/internal/constant/ReferenceClassDescImpl",
>>>>>     "java/lang/constant/ConstantDescs",
>>>>>     "sun/invoke/util/Wrapper",
>>>>>
>>>>> I was having a similar circularity issue (but in production time) and
>>>>> I just added enough classes to make the NPE go away. For your test case, if
>>>>> you manage to fix in in the assembly run but run into NPE in production
>>>>> run, you might need to add more classes to this list. Yes, it's a hack :-(
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> - Ioi
>>>>> On 9/13/24 7:05 PM, Ashutosh Mehra wrote:
>>>>>
>>>>> This is turning out to be a real example of class initialization soup!
>>>>> As mentioned during the meeting, I am getting NPE in the assembly
>>>>> phase when testing the patch [0] that I proposed in my earlier mail
>>>>> using a test case inspired by the Infinispan code.
>>>>> NPE occurs when running the class initializer for
>>>>> PrimitiveClassDescImpl
>>>>> Interestingly, PrimitiveClassDescImpl is "forcefully" initialized by
>>>>> MetaspaceShared::link_shared_classes().
>>>>>
>>>>> I couldn't get a stack trace so I relied on exception logs (using
>>>>> -Xlog:exceptions=trace) to find the cause which indicate following frames
>>>>> on the stack:
>>>>>
>>>>> [0]
>>>>> jdk/internal/constant/MethodTypeDescImpl::validateArgument(Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/ClassDesc; @
>>>>> bci 1
>>>>> [1]
>>>>> jdk/internal/constant/MethodTypeDescImpl::ofTrusted(Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljdk/internal/constant/MethodTypeDescImpl; @
>>>>> bci 27
>>>>> [2]
>>>>> java/lang/constant/ConstantDescs::ofConstantBootstrap(Ljava/lang/constant/ClassDesc;Ljava/lang/String;Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/DirectMethodHandleDesc; @
>>>>> bci 47
>>>>> [3] java/lang/constant/ConstantDescs::<clinit> @ bci 664
>>>>> [4]
>>>>> jdk/internal/constant/PrimitiveClassDescImpl::<init>(Ljava/lang/String;)V @
>>>>> bci 1
>>>>> [5]
>>>>> jdk/internal/constant/PrimitiveClassDescImpl::<clinit>(Ljava/lang/String;)V @
>>>>> bci 6
>>>>>
>>>>> Notice that invocation of PrimitiveClassDescImpl::<clinit> results in
>>>>> initialization of ConstantDescs class (see frame 3).
>>>>> ConstantDescs::<clinit> @ 664 corresponds to following java code:
>>>>>
>>>>>     public static final DirectMethodHandleDesc BSM_CLASS_DATA_AT
>>>>>             = ofConstantBootstrap(CD_MethodHandles, "classDataAt",
>>>>>             CD_Object, CD_int);
>>>>>
>>>>> The last parameter CD_int is initialized as:
>>>>>
>>>>>     public static final ClassDesc CD_int =
>>>>> PrimitiveClassDescImpl.CD_int;
>>>>>
>>>>> So, its value is obtained from PrimitiveClassDescImpl.CD_int which
>>>>> hasn't been initialized properly yet. As a result ConstantDescs::CD_int
>>>>> is assigned null which results in MethodTypeDescImpl::validateArgument
>>>>> throwing NPE later.
>>>>> There is a clear class initialization circularity involving
>>>>> PrimitiveClassDescImpl and ConstantDescs, and the result depends on
>>>>> which class gets initialized first.
>>>>>
>>>>> Without my patch this issue is not seen because PrimitiveClassDescImpl
>>>>> has already been initialized by the time
>>>>> MetaspaceShared::link_shared_classes() is called.
>>>>> Its initialization is triggered by the call to
>>>>> MethodType::createArchivedObjects().
>>>>> It also explains why my patch introduced this issue because it
>>>>> effectively moved the call to MethodType::createArchivedObjects()
>>>>> after MetaspaceShared::link_shared_classes().
>>>>>
>>>>> [0]
>>>>> https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>>>> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>>>>
>>>>> Thanks,
>>>>> - Ashutosh Mehra
>>>>>
>>>>>
>>>>> On Wed, Sep 11, 2024 at 3:12?PM Ashutosh Mehra <asmehra at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Regarding the WrongMethodTypeException that I mentioned in my
>>>>>> previous email (see pt 3),
>>>>>> this exception happens when lambda proxy class attempts to invoke the
>>>>>> MethodHandle it obtained from the classData:
>>>>>>
>>>>>>   public void accept(java.lang.Object);
>>>>>>     descriptor: (Ljava/lang/Object;)V
>>>>>>     flags: (0x0001) ACC_PUBLIC
>>>>>>     Code:
>>>>>>       stack=3, locals=2, args_size=2
>>>>>>          0: ldc           #26                 // Dynamic
>>>>>> #0:_:Ljava/lang/invoke/MethodHandle;
>>>>>>          2: aload_0
>>>>>>          3: getfield      #13                 // Field
>>>>>> arg$1:Lorg/wildfly/security/WildFlyElytronBaseProvider;
>>>>>>          6: aload_1
>>>>>>          7: checkcast     #28                 // class
>>>>>> java/security/Provider$Service
>>>>>>         10: invokevirtual #34                 // Method
>>>>>> java/lang/invoke/MethodHandle.invokeExact:(Lorg/wildfly/security/WildFlyElytronBaseProvider;Ljava/security/Provider$Service;)V
>>>>>>         13: return
>>>>>>
>>>>>> The scenario is during the assembly phase as part of the indy
>>>>>> resolution the MethodHandle for which the exception is thrown gets created.
>>>>>> Normally MethodHandle's type gets added in MethodType::internTable
>>>>>> but by the time indy resolution happens, JVM has already taken
>>>>>> snapshot of the MethodType::internTable through an upcall to
>>>>>> MethodType::createArchivedObjects().
>>>>>> As a result the AOTCache ends up with the MethodType object which is
>>>>>> not in AOTHolder.archivedMethodTypes.
>>>>>>
>>>>>> During the production run, when the jvm invokes the MethodHandle, it
>>>>>> searches for the MethodType corresponding to the signature passed at the
>>>>>> callsite.
>>>>>> As expected, it fails to find it in the AOTHolder.archivedMethodTypes,
>>>>>> so it creates a new instance of the MethodType.
>>>>>> But Invokers.checkExactType() relies on the MethodHandle's type to
>>>>>> be the same object as the MethodType object passed as parameter.
>>>>>>
>>>>>>     static void checkExactType(MethodHandle mhM, MethodType
>>>>>> expected) {
>>>>>>         MethodType targetType = mh.type();
>>>>>>         if (targetType != expected)
>>>>>>             throw newWrongMethodTypeException(targetType, expected);
>>>>>>     }
>>>>>>
>>>>>> Hence, it throws WrongMethodTypeException though the two MT objects
>>>>>> have the same signature.
>>>>>>
>>>>>> To handle this scenario, I changed the order of indy resolution and upcall
>>>>>> to MethodType::createArchivedObjects() as:
>>>>>>
>>>>>> diff --git a/src/hotspot/share/cds/metaspaceShared.cpp
>>>>>> b/src/hotspot/share/cds/metaspaceShared.cpp
>>>>>> index df4bcadefa3..457716cac5b 100644
>>>>>> --- a/src/hotspot/share/cds/metaspaceShared.cpp
>>>>>> +++ b/src/hotspot/share/cds/metaspaceShared.cpp
>>>>>> @@ -751,6 +751,20 @@ void MetaspaceShared::link_shared_classes(bool
>>>>>> jcmd_request, TRAPS) {
>>>>>>    if (CDSConfig::is_dumping_final_static_archive()) {
>>>>>>      FinalImageRecipes::apply_recipes(CHECK);
>>>>>>    }
>>>>>> +
>>>>>> +#if INCLUDE_CDS_JAVA_HEAP
>>>>>> +  if (CDSConfig::is_dumping_invokedynamic()) {
>>>>>> +    // This makes sure that the MethodType and MethodTypeForm tables
>>>>>> won't be updated
>>>>>> +    // concurrently when we are saving their contents into a side
>>>>>> table.
>>>>>> +    assert(CDSConfig::allow_only_single_java_thread(), "Required");
>>>>>> +
>>>>>> +    JavaValue result(T_VOID);
>>>>>> +    JavaCalls::call_static(&result, vmClasses::MethodType_klass(),
>>>>>> +                           vmSymbols::createArchivedObjects(),
>>>>>> +                           vmSymbols::void_method_signature(),
>>>>>> +                           CHECK);
>>>>>> +  }
>>>>>> +#endif
>>>>>>  }
>>>>>>
>>>>>> Note that indy resolution happens as part of FinalImageRecipes::apply_recipes(CHECK)
>>>>>> which is now invoked before the upcall to createArchivedObjects().
>>>>>> With this change I am able to run the application without any
>>>>>> exceptions.
>>>>>> My complete patch can be seen here:
>>>>>> https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>>>>> <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>>>>> I will do more testing with this patch.
>>>>>>
>>>>>> @Ioi Lam <ioi.lam at oracle.com> do you have any feedback on this patch.
>>>>>>
>>>>>> Thanks,
>>>>>> - Ashutosh Mehra
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 11, 2024 at 10:14?AM Ashutosh Mehra <asmehra at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Andrew,
>>>>>>> Thanks for sharing the initial investigation.
>>>>>>> I have been looking into this and have a few of things to add to
>>>>>>> your analysis:
>>>>>>>
>>>>>>> 1.  As you mentioned the classData for the lambda
>>>>>>> class WildFlyElytronBaseProvider$$Lambda is null.
>>>>>>> The classData is stored in the mirror object of the InstanceKlass
>>>>>>> when the class is defined through JVM_LookupDefineClass.
>>>>>>> However, when we create the scratch mirror object (which get stored
>>>>>>> in the AOT cache) the classData is not populated.
>>>>>>> See
>>>>>>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp#L1128-L1131
>>>>>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp*L1128-L1131__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhbKjzG3gw$>
>>>>>>>
>>>>>>>   Handle classData; // set to null. Will be reinitialized at runtime
>>>>>>>   Handle mirror;
>>>>>>>   Handle comp_mirror;
>>>>>>>   allocate_mirror(k, /*is_scratch=*/true, protection_domain,
>>>>>>> classData, mirror, comp_mirror, CHECK);
>>>>>>>
>>>>>>> So this explains why the call to classData(caller.lookupClass())
>>>>>>> returned null.
>>>>>>>
>>>>>>> 2. In the mainline there is a check
>>>>>>> in InnerClassLambdaMetafactory.java for the particular code pattern used by
>>>>>>> the application.
>>>>>>> If this code pattern is found then the lambda proxy class is not
>>>>>>> included in the CDS archive.
>>>>>>> See
>>>>>>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L163-L170
>>>>>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L163-L170__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZl2S9tQg$>
>>>>>>> and
>>>>>>> https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L246
>>>>>>> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L246__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhYsI3Xx0g$>
>>>>>>>
>>>>>>>         // If the target class invokes a protected method inherited
>>>>>>> from a
>>>>>>>         // superclass in a different package, or does
>>>>>>> 'invokespecial', the
>>>>>>>         // lambda class has no access to the resolved method, or does
>>>>>>>         // 'invokestatic' on a hidden class which cannot be resolved
>>>>>>> by name.
>>>>>>>         // Instead, we need to pass the live implementation method
>>>>>>> handle to
>>>>>>>         // the proxy class to invoke directly. (javac prefers to
>>>>>>> avoid this
>>>>>>>         // situation by generating bridges in the target class)
>>>>>>>         useImplMethodHandle =
>>>>>>> (Modifier.isProtected(implInfo.getModifiers()) &&
>>>>>>>
>>>>>>>  !VerifyAccess.isSamePackage(targetClass, implInfo.getDeclaringClass())) ||
>>>>>>>                                implKind ==
>>>>>>> MethodHandleInfo.REF_invokeSpecial ||
>>>>>>>                                implKind ==
>>>>>>> MethodHandleInfo.REF_invokeStatic && implClass.isHidden();
>>>>>>>
>>>>>>> In premain lambda proxy classes get included in the AOT cache as a
>>>>>>> result of indy resolution and that mechanism doesn't have this kind of
>>>>>>> check.
>>>>>>>
>>>>>>> 3. For the null classData problem mentioned above, I tried to fix it
>>>>>>> by storing classData in the scratch mirror using the following patch:
>>>>>>>
>>>>>>> diff --git a/src/hotspot/share/classfile/javaClasses.cpp
>>>>>>> b/src/hotspot/share/classfile/javaClasses.cpp
>>>>>>> index bd8141adbcc..41766e98093 100644
>>>>>>> --- a/src/hotspot/share/classfile/javaClasses.cpp
>>>>>>> +++ b/src/hotspot/share/classfile/javaClasses.cpp
>>>>>>> @@ -1094,9 +1094,9 @@ void java_lang_Class::create_mirror(Klass* k,
>>>>>>> Handle class_loader,
>>>>>>>      }
>>>>>>>      if (CDSConfig::is_dumping_heap()) {
>>>>>>>        if (CDSConfig::is_dumping_protection_domains()) {
>>>>>>> -        create_scratch_mirror(k, protection_domain, CHECK);
>>>>>>> +        create_scratch_mirror(k, protection_domain, classData,
>>>>>>> CHECK);
>>>>>>>        } else {
>>>>>>> -        create_scratch_mirror(k, Handle() /* null
>>>>>>> protection_domain*/, CHECK);
>>>>>>> +        create_scratch_mirror(k, Handle() /* null
>>>>>>> protection_domain*/, classData, CHECK);
>>>>>>>        }
>>>>>>>      }
>>>>>>>    } else {
>>>>>>> @@ -1117,7 +1117,7 @@ void java_lang_Class::create_mirror(Klass* k,
>>>>>>> Handle class_loader,
>>>>>>>  // Note: we archive the "scratch mirror" instead of
>>>>>>> k->java_mirror(), because the
>>>>>>>  // latter may contain dumptime-specific information that cannot be
>>>>>>> archived
>>>>>>>  // (e.g., ClassLoaderData*, or static fields that are modified by
>>>>>>> Java code execution).
>>>>>>> -void java_lang_Class::create_scratch_mirror(Klass* k, Handle
>>>>>>> protection_domain, TRAPS) {
>>>>>>> +void java_lang_Class::create_scratch_mirror(Klass* k, Handle
>>>>>>> protection_domain, Handle classData, TRAPS) {
>>>>>>>    if (k->class_loader() != nullptr &&
>>>>>>>        k->class_loader() != SystemDictionary::java_platform_loader()
>>>>>>> &&
>>>>>>>        k->class_loader() != SystemDictionary::java_system_loader()) {
>>>>>>> @@ -1125,9 +1125,11 @@ void
>>>>>>> java_lang_Class::create_scratch_mirror(Klass* k, Handle protection_domain,
>>>>>>>      return;
>>>>>>>    }
>>>>>>>
>>>>>>> -  Handle classData; // set to null. Will be reinitialized at runtime
>>>>>>> +  //Handle classData; // set to null. Will be reinitialized at
>>>>>>> runtime
>>>>>>>    Handle mirror;
>>>>>>>    Handle comp_mirror;
>>>>>>>    allocate_mirror(k, /*is_scratch=*/true, protection_domain,
>>>>>>> classData, mirror, comp_mirror, CHECK);
>>>>>>>
>>>>>>>    if (comp_mirror() != nullptr) {
>>>>>>> diff --git a/src/hotspot/share/classfile/javaClasses.hpp
>>>>>>> b/src/hotspot/share/classfile/javaClasses.hpp
>>>>>>> index bc49a0861a7..7ec2a2556dd 100644
>>>>>>> --- a/src/hotspot/share/classfile/javaClasses.hpp
>>>>>>> +++ b/src/hotspot/share/classfile/javaClasses.hpp
>>>>>>> @@ -263,7 +263,7 @@ class java_lang_Class : AllStatic {
>>>>>>>
>>>>>>>    // Archiving
>>>>>>>    static void serialize_offsets(SerializeClosure* f) NOT_CDS_RETURN;
>>>>>>> -  static void create_scratch_mirror(Klass* k, Handle
>>>>>>> protection_domain, TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>>>>>>> +  static void create_scratch_mirror(Klass* k, Handle
>>>>>>> protection_domain, Handle classData, TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
>>>>>>>    static bool restore_archived_mirror(Klass *k, Handle
>>>>>>> class_loader, Handle module,
>>>>>>>                                        Handle protection_domain,
>>>>>>>                                        TRAPS)
>>>>>>> NOT_CDS_JAVA_HEAP_RETURN_(false);
>>>>>>>
>>>>>>> But this resulted in a different exception:
>>>>>>>
>>>>>>> Exception in thread "main" java.lang.ExceptionInInitializerError
>>>>>>> at com.redhat.leyden.Main.main(Main.java:7)
>>>>>>> Caused by: java.lang.invoke.WrongMethodTypeException: handle's
>>>>>>> method type (WildFlyElytronBaseProvider,Service)void but found
>>>>>>> (WildFlyElytronBaseProvider,Service)void
>>>>>>> at
>>>>>>> java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>>>>>>> at
>>>>>>> java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>>>>>>> at
>>>>>>> java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
>>>>>>> at
>>>>>>> org.wildfly.security.WildFlyElytronBaseProvider$$Lambda/0x80000000c.accept(Unknown
>>>>>>> Source)
>>>>>>> at
>>>>>>> org.wildfly.security.WildFlyElytronBaseProvider.putMakedPasswordImplementations(WildFlyElytronBaseProvider.java:112)
>>>>>>> at
>>>>>>> org.wildfly.security.WildFlyElytronBaseProvider.putPasswordImplementations(WildFlyElytronBaseProvider.java:107)
>>>>>>> at
>>>>>>> org.wildfly.security.password.WildFlyElytronPasswordProvider.<init>(WildFlyElytronPasswordProvider.java:43)
>>>>>>> at
>>>>>>> org.wildfly.security.password.WildFlyElytronPasswordProvider.<clinit>(WildFlyElytronPasswordProvider.java:36)
>>>>>>> ... 1 more
>>>>>>>
>>>>>>> The exception message is strange because the handle's method type
>>>>>>> and the expected type are both symbolically the same.
>>>>>>> I am debugging this exception at the moment.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> - Ashutosh Mehra
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 11, 2024 at 6:03?AM Andrew Dinn <adinn at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Oops, sorry, I debugged this a few days ago! Correction to a few
>>>>>>>> details:
>>>>>>>>
>>>>>>>> On 11/09/2024 10:39, Andrew Dinn wrote:
>>>>>>>> > A crash due to an NPE was observed in the Infinispan (Data Grid)
>>>>>>>> server
>>>>>>>> > app when deployed using the Leyden EA. The crash still manifests
>>>>>>>> with
>>>>>>>> > the latest premain code. The crash happens below an application
>>>>>>>> call
>>>>>>>> > which employs a method reference as argument
>>>>>>>> >
>>>>>>>> >          putMakedPasswordImplementations(this::putService, this);
>>>>>>>>
>>>>>>>> The called method in turn calls consumer.accept
>>>>>>>>
>>>>>>>>              consumer.accept(new Service(provider,
>>>>>>>> PASSWORD_FACTORY_TYPE, algorithm,
>>>>>>>> "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>>>>>>> emptyList,
>>>>>>>> emptyMap));
>>>>>>>>
>>>>>>>> which enters enters MethodHandleNative::linkDynamicConstant()
>>>>>>>>
>>>>>>>> > Debugging shows that the call to linkDynamicConstant() returns
>>>>>>>> null.
>>>>>>>> >
>>>>>>>> > A simple reproducer for the problem is available as a maven
>>>>>>>> project on
>>>>>>>> > github:
>>>>>>>> >
>>>>>>>> >    https://github.com/tristantarrant/elytron-leyden
>>>>>>>> <https://urldefense.com/v3/__https://github.com/tristantarrant/elytron-leyden__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZaZr1akQ$>
>>>>>>>> >
>>>>>>>> > The ReadMe provides an explanation of how to reproduce the
>>>>>>>> problem. I
>>>>>>>> > did so and the debugged to find out some of the details of what
>>>>>>>> is
>>>>>>>> > happening (see below) but did not fully clarify the problem. Help
>>>>>>>> from
>>>>>>>> > someone more conversant with the ins and outs of method handle
>>>>>>>> > bootstraps in premain would be welcome. Details follow.
>>>>>>>> >
>>>>>>>> > regards,
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > Andrew Dinn
>>>>>>>> > -----------
>>>>>>>> >
>>>>>>>> > I downloaded the git repo and attached the Java sources using
>>>>>>>> Maven command
>>>>>>>> >
>>>>>>>> >    $ mvn dependency:sources
>>>>>>>> >
>>>>>>>> > Having manifested the crash by following the instructions in the
>>>>>>>> README
>>>>>>>> > I reran the leyden JVM under gdb using the following commands to
>>>>>>>> enable
>>>>>>>> > Java debugging
>>>>>>>> >
>>>>>>>> > $ gdb ${LEYDEN_HOME}/bin/java
>>>>>>>> > (gdb) cd /path/to/mvn/project
>>>>>>>> > (gdb) run
>>>>>>>> >
>>>>>>>> -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
>>>>>>>> > -classpath
>>>>>>>> >
>>>>>>>> /home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/
>>>>>>>> 2.5.1.
>>>>>>>> <https://urldefense.com/v3/__http://2.5.1.__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhauJ-RjcQ$>Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar
>>>>>>>> -XX:CacheDataStore=elytron.aot com.redhat.leyden.Main
>>>>>>>> >
>>>>>>>> > The problem manifests at WildflyElytronBaseProvider.java:112 in
>>>>>>>> method
>>>>>>>> > WildflyElytronBaseProvider::putMakedPasswordImplementations
>>>>>>>>
>>>>>>>>      static void putMakedPasswordImplementations(Consumer<Service>
>>>>>>>> consumer, Provider provider) {
>>>>>>>>          for (String algorithm : MASKED_ALGORITHMS) {
>>>>>>>>              consumer.accept(new Service(provider,
>>>>>>>> PASSWORD_FACTORY_TYPE, algorithm,
>>>>>>>> "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>>>>>>> emptyList,
>>>>>>>> emptyMap)); <== NPE under this call
>>>>>>>>          }
>>>>>>>>
>>>>>>>>
>>>>>>>> > The source code for this method can be found in the following
>>>>>>>> source jar
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> ${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar
>>>>>>>> >
>>>>>>>> > (where M2_REPO will normally be ~/.m2/repository)
>>>>>>>> >
>>>>>>>> > Stepping into accept eventually enters
>>>>>>>> MethodHandleNative::linkDynamicConstant
>>>>>>>> > which in turn enters into ConstantBootstraps.makeConstant(). The
>>>>>>>> caller
>>>>>>>> > Class at this point is a lambda class which prints as
>>>>>>>> >
>>>>>>>> org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c
>>>>>>>> >
>>>>>>>> > Several steps further the code enters
>>>>>>>> BootstrapMethodInvoker::invoke
>>>>>>>> > (below the app method call but via 3 hidden frames) with
>>>>>>>> bootstrapMethod
>>>>>>>> > bound to a DirectMethodHandle. After several more steps this
>>>>>>>> enters
>>>>>>>> > DirectMethodHandle$Holder.invokeStatic which in turn calls
>>>>>>>> > MethodHandles::classData(Lookup,String,Class).
>>>>>>>> >
>>>>>>>> > At this point caller is a MethodHandleLookup for the lambda class
>>>>>>>> > Lambda/0x800000000c mentioned above. The following call
>>>>>>>> >
>>>>>>>> >           Object classdata = classData(caller.lookupClass());
>>>>>>>> >
>>>>>>>> > returns null to DirectMethodHandle$Holder.invokeStatic which pops
>>>>>>>> the
>>>>>>>> > same result back out to BootstrapMethodInvoker::invoke at line 90
>>>>>>>> >
>>>>>>>> >                  if (type instanceof Class<?> c) {
>>>>>>>> >                      result = bootstrapMethod.invoke(caller,
>>>>>>>> name, c);
>>>>>>>> > <== null
>>>>>>>> >
>>>>>>>> > This null result pops back out as the value for the call to
>>>>>>>> > BootstrapMethodInvoker.invoke(),
>>>>>>>> ConstantBootstraps.makeConstant() and
>>>>>>>> > MethodHandleNative::linkDynamicConstant().
>>>>>>>> >
>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240924/cb233e80/attachment.htm>

From adinn at openjdk.org  Wed Sep 25 13:58:15 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 25 Sep 2024 13:58:15 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v4]
In-Reply-To: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
Message-ID: <_p2-w-OWX8jH2O90d5IyoesFGlfconxRy7TU28mOKZo=.d60c7b86-ed0e-4049-ac82-5dc0eced8fc0@github.com>

> This PR modifies AOT compiled method code to load compressed oops base and shift constants via the AOTRuntimeConstants area rather than encode them as immediates. It also unlatches the currently forced setting of UseCompatibleCompressedOops, allowing the heap to be allocated wherever it will fit.

Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:

  fix oop decode not to side-effect flags

-------------

Changes:
  - all: https://git.openjdk.org/leyden/pull/20/files
  - new: https://git.openjdk.org/leyden/pull/20/files/243d72d5..7ba14a6e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=leyden&pr=20&range=03
 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=20&range=02-03

  Stats: 12 lines in 1 file changed: 9 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/leyden/pull/20.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/20/head:pull/20

PR: https://git.openjdk.org/leyden/pull/20

From adinn at openjdk.org  Wed Sep 25 14:45:53 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 25 Sep 2024 14:45:53 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v4]
In-Reply-To: <_p2-w-OWX8jH2O90d5IyoesFGlfconxRy7TU28mOKZo=.d60c7b86-ed0e-4049-ac82-5dc0eced8fc0@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
 <_p2-w-OWX8jH2O90d5IyoesFGlfconxRy7TU28mOKZo=.d60c7b86-ed0e-4049-ac82-5dc0eced8fc0@github.com>
Message-ID: <OBqZJwo1lyPZ5kz7bmaGw1BYxX2s3lrm0Ek9-IbpLTk=.53638bfb-c127-4845-90fc-fc08808197e4@github.com>

On Wed, 25 Sep 2024 13:58:15 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> This PR modifies AOT compiled method code to load compressed oops base and shift constants via the AOTRuntimeConstants area rather than encode them as immediates. It also unlatches the currently forced setting of UseCompatibleCompressedOops, allowing the heap to be allocated wherever it will fit.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix oop decode not to side-effect flags

I debugged the deopt and found that the interpreter frame was restored at the ifeq (bci 109) as you might expect but that the restored top of stack was `0xdeaddeaf00000001`. This value ought to have been 0 since we were seeing a failed instanceof.

Digging deeper I found that the problem was actually in the generated method code. The problem was actually an aarch64 compiler/macro assembler issue because C2 had interleaved an oop decode between the ifeq test (cmp) and subsequent deopt branch (beq). This was down to a detail of how I implemented the decode for aot code.

My implementation of `decode_heap_oop_for_aot` followed `encode_heap_oop_for_aot` by using `cmp` + `csel`. However, I failed to notice that `encode_heap_oop` can only use `cmp` + `csel` safely because C2 instruction `encodeHeapOop` declares `effect(KILL cr)`. I could have fixed this by adding a kill effect to `decodeheapOop` but instead I thought it safer to modify `decode_heap_oop_for_aot` to follow `decode_heap_oop` and employ a local `cbnz` branch. This has fixed the problem.

I'll try to get some performance figures now that it is working.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/20#issuecomment-2374302414

From duke at openjdk.org  Wed Sep 25 14:50:37 2024
From: duke at openjdk.org (duke)
Date: Wed, 25 Sep 2024 14:50:37 GMT
Subject: git: openjdk/leyden: premain: 4 new changesets
Message-ID: <6d9d5e7d-a1f5-4a77-ba1c-77668f2c51bd@openjdk.org>

Changeset: 7a6fadca
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-09-24 21:40:28 +0000
URL:       https://git.openjdk.org/leyden/commit/7a6fadcae03d86c91713ffae452817bce7a4674d

8340869: [premain] NullPointerException with LambdaWithUseImplMethodHandle.java

! src/hotspot/share/cds/aotClassInitializer.cpp
! src/hotspot/share/cds/aotClassInitializer.hpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! test/hotspot/jtreg/runtime/cds/appcds/LambdaWithUseImplMethodHandle.java

Changeset: ac3f40d0
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-09-24 22:09:11 +0000
URL:       https://git.openjdk.org/leyden/commit/ac3f40d023c72a29e29153b121d98fbf26944bb7

8340836: Method.invoke fails with java.lang.AssertionError with AOTClassLinking and system assertions enabled

! src/hotspot/share/cds/aotClassInitializer.cpp
! src/hotspot/share/cds/aotClassLinker.cpp
! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
+ test/hotspot/jtreg/runtime/cds/appcds/resolvedConstants/AOTLinkedLambdas.java

Changeset: 21d3ed73
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-09-24 22:38:45 +0000
URL:       https://git.openjdk.org/leyden/commit/21d3ed736efc071a9326a3493501a54cb72f4867

Merged some code from upstreaming PRs of JEP 483

! src/hotspot/share/cds/aotClassInitializer.cpp
! src/hotspot/share/cds/aotClassInitializer.hpp
! src/hotspot/share/cds/cdsHeapVerifier.cpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/heapShared.hpp
! src/java.base/share/classes/java/lang/Boolean.java

Changeset: 9cf06243
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-09-25 07:48:54 +0000
URL:       https://git.openjdk.org/leyden/commit/9cf06243aa409dc5717a00b735776c672b80f2a4

Added some CDSHeapVerifier rules for ArchiveLoaderLookupCache

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


From ioi.lam at oracle.com  Wed Sep 25 14:52:05 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Wed, 25 Sep 2024 07:52:05 -0700
Subject: [External] : Re: premain: Crash in Infinispan server code caused
 by NPE under MethodHandleNative::linkDynamicConstant
In-Reply-To: <CAKt0pyTixr_fwL-f+=zuRv38a2=3tXHRct2tVAVLvgrp7jVYhg@mail.gmail.com>
References: <882253a8-dfba-4b17-9f16-030f85981419@redhat.com>
 <50855387-cec4-40fa-b257-39bb82b3149e@redhat.com>
 <CAKt0pySztvwsadtrqjai6XwakAWq_v_o8men4aopLo4X-0azyQ@mail.gmail.com>
 <CAKt0pyQ44E+npyUW35Zhxg+PfBgF2yuNgS61gj1GGj=aLGTJXw@mail.gmail.com>
 <CAKt0pyT48uPH6rUL7bEJ2rtWqNdNL34DWBJ2SDaHwYfVxURnQw@mail.gmail.com>
 <0d22d580-39a1-4105-a50e-8a74a555090d@oracle.com>
 <CAKt0pyRYBNtkLzVoAfDHWE=4e+9efZFb+xKYZv-d3LpDAU4qZg@mail.gmail.com>
 <da797fe2-137c-4fc7-a67c-3b595c0c63f2@oracle.com>
 <CAKt0pyRj8_mDiH58v10sqXNHA4iHja6-7D9N_S2VW9rhESPcTw@mail.gmail.com>
 <45e62b78-bbde-4ba5-8b20-77125d14b908@oracle.com>
 <4dc70b95-f014-44f1-acfb-027c8e28e81d@oracle.com>
 <CAKt0pyQ8T+-yZQ1UJBewcc_DXTMRymNRSp3cz4xCZf54XUhw+g@mail.gmail.com>
 <9ec705a7-4fa5-40f8-8685-b49c54ab4418@oracle.com>
 <CAKt0pyTQXoW82Dx=BRFx93_wm6dEiCcncT66mDOHGXt4GqiE0Q@mail.gmail.com>
 <199d99cb-5e4c-40c6-a9b5-3e5e456f1968@oracle.com>
 <CAKt0pyTixr_fwL-f+=zuRv38a2=3tXHRct2tVAVLvgrp7jVYhg@mail.gmail.com>
Message-ID: <31f7f6f2-21b5-461b-9591-72c59e6fb78d@oracle.com>

HI Ashutosh,

Thanks for confirming. I created a JBS issue for this and pushed the fix:

https://bugs.openjdk.org/browse/JDK-8340869
https://github.com/openjdk/leyden/commit/7a6fadcae03d86c91713ffae452817bce7a4674d

Thanks

- Ioi

On 9/24/24 6:36 PM, Ashutosh Mehra wrote:
>
>     I disabled the AOTClassInitializer::is_forced_preinit_class() call
>     and synced
>     AOTClassInitializer::can_archive_preinitialized_mirror() with my
>     upstream PR. This seems to fix the error in your test case.
>
>
> I verified that this change?fixes the error in the testcase. Thanks 
> for fixing this issue.
>
> - Ashutosh Mehra
>
>
> On Tue, Sep 24, 2024 at 1:01?PM <ioi.lam at oracle.com> wrote:
>
>     Hi Ashutosh,
>
>     I disabled the AOTClassInitializer::is_forced_preinit_class() call
>     and synced
>     AOTClassInitializer::can_archive_preinitialized_mirror() with my
>     upstream PR. This seems to fix the error in your test case.
>
>     Could you give it a try?
>
>     https://github.com/iklam/jdk/commit/df72d0ba8dc799767521c939a531c4128e58c636
>     <https://urldefense.com/v3/__https://github.com/iklam/jdk/commit/df72d0ba8dc799767521c939a531c4128e58c636__;!!ACWV5N9M2RV99hQ!JlCvAYhu5kpAYkOTVF5UgMSFalpCIQtIFb-TURRezEh4nHbqPTRgCJPjokWlgwcGFibvjMg1fnNZBg$>
>
>     Thanks
>
>     - Ioi
>
>
>     https://github.com/iklam/jdk/commit/df72d0ba8dc799767521c939a531c4128e58c636
>     <https://urldefense.com/v3/__https://github.com/iklam/jdk/commit/df72d0ba8dc799767521c939a531c4128e58c636__;!!ACWV5N9M2RV99hQ!JlCvAYhu5kpAYkOTVF5UgMSFalpCIQtIFb-TURRezEh4nHbqPTRgCJPjokWlgwcGFibvjMg1fnNZBg$>
>
>     On 9/24/24 8:24 AM, Ashutosh Mehra wrote:
>>     Hi Ioi,
>>     Thanks for sharing the code changes.
>>     The wildfly-elytron testcase passes with these changes, but I
>>     still get the NPE in?PrimitiveClassDescImpl.<clinit> when running
>>     with my own testcase.
>>     I have pushed my test case to a repo [2], so you can try it as
>>     well. I have added some instructions to the Readme file.
>>     Let me know if you face any issues in running the test case.
>>
>>     [2] https://github.com/ashu-mehra/leyden-testcase/
>>     <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden-testcase/__;!!ACWV5N9M2RV99hQ!JiRlHQ7c-vdXVJoc61a64CilNOg5VTLitO8JELhohSZdibAXZUEjeA38WbtygjLvPsQIQKUYXJ2_kA$>
>>
>>     Thanks,
>>     - Ashutosh Mehra
>>
>>
>>     On Mon, Sep 23, 2024 at 11:24?PM <ioi.lam at oracle.com> wrote:
>>
>>         Hi Ashutosh,
>>
>>         Thank you again for the summary of the issues.
>>
>>         I looked at the call paths again and I think two calls need
>>         to be moved
>>
>>             (1) MethodType::createArchivedObjects() needs to be
>>             called after we have executed all other Java code. So I
>>             put it before the
>>             StringTable::allocate_shared_strings_array() call.
>>
>>             (2) SystemDictionary::get_all_method_handle_intrinsics()
>>             needs to be done inside the safepoint, so it can be sure
>>             to find all the method handle intrinsic methods (which
>>             can be generated as the side effect of Java code execution).
>>
>>             I also added the archiving of the classData field.
>>
>>         See my temporary change at
>>         https://github.com/iklam/jdk/commit/eafaa9731ae89b93f3e20702fc4d5a12cb070149
>>         <https://urldefense.com/v3/__https://github.com/iklam/jdk/commit/eafaa9731ae89b93f3e20702fc4d5a12cb070149__;!!ACWV5N9M2RV99hQ!JiRlHQ7c-vdXVJoc61a64CilNOg5VTLitO8JELhohSZdibAXZUEjeA38WbtygjLvPsQIQKXvE8zr1g$>
>>
>>         With this change, I am able to successfully run the test in
>>         https://github.com/tristantarrant/elytron-leyden
>>         <https://urldefense.com/v3/__https://github.com/tristantarrant/elytron-leyden__;!!ACWV5N9M2RV99hQ!JiRlHQ7c-vdXVJoc61a64CilNOg5VTLitO8JELhohSZdibAXZUEjeA38WbtygjLvPsQIQKW7YFmGjQ$>
>>         . I also modified the LambdaWithUseImplMethodHandle.java test
>>         to add a similar test scenario.
>>
>>         I agree with you that the code in
>>         AOTClassInitializer::is_forced_preinit_class() is too ad-hoc,
>>         and might change the order of class initialization. In the
>>         upstream PR, I have changed the code to only assert that the
>>         listed of classes has been initialized:
>>
>>         https://github.com/iklam/jdk/blob/5cc31ed60cc9597d63b86f20b95c964d4d1a6b84/src/hotspot/share/cds/aotClassInitializer.cpp#L66-L84
>>         <https://urldefense.com/v3/__https://github.com/iklam/jdk/blob/5cc31ed60cc9597d63b86f20b95c964d4d1a6b84/src/hotspot/share/cds/aotClassInitializer.cpp*L66-L84__;Iw!!ACWV5N9M2RV99hQ!JiRlHQ7c-vdXVJoc61a64CilNOg5VTLitO8JELhohSZdibAXZUEjeA38WbtygjLvPsQIQKUJSR9oEw$>
>>
>>         I will try to merge this version of the code back to the
>>         Leyden repo.
>>
>>         I think by doing this, we can avoid direct manipulation of
>>         the class-init order of the core-library classes. Instead, we
>>         just make sure that we execute enough "normal" code during
>>         the assembly phase to ensure that these classes are
>>         initialized in their normal order.
>>
>>         What do you think?
>>
>>         Thanks
>>
>>         - Ioi
>>
>>
>>         On 9/19/24 8:05 PM, Ashutosh Mehra wrote:
>>>
>>>             Upon further investigation, it seems a simple patch
>>>             might fix the problem with classData.
>>>
>>>             I tested with
>>>             test/hotspot/jtreg/runtime/cds/appcds/LambdaWithUseImplMethodHandle.java
>>>             by running jtreg with -javaoptions:-XX:+AOTClassLinking
>>>             Without the patch, I'd get a NullPointerException. With
>>>             the patch, the test passes.
>>>
>>>             It looks like classData is not treated as a static field
>>>             of the class, but rather an instance field in the
>>>             mirror. So classData wasn't copied by the loop in
>>>             HeapShared::copy_preinitialized_mirror().
>>>
>>>             Ashutosh, could you try it this fixes the crash on your
>>>             side?
>>>
>>>             Thanks
>>>
>>>             - Ioi
>>>
>>>             diff --git a/src/hotspot/share/cds/heapShared.cpp
>>>             b/src/hotspot/share/cds/heapShared.cpp
>>>             index 0e70778f057..62cf142f67a 100644
>>>             --- a/src/hotspot/share/cds/heapShared.cpp
>>>             +++ b/src/hotspot/share/cds/heapShared.cpp
>>>             @@ -634,6 +634,8 @@ void
>>>             HeapShared::copy_preinitialized_mirror(Klass* orig_k,
>>>             oop orig_mirror, oop
>>>             ???? }
>>>             ?? }
>>>
>>>             +? java_lang_Class::set_class_data(m,
>>>             java_lang_Class::class_data(orig_mirror));
>>>             +
>>>             ?? // Class::reflectData use SoftReference, which cannot
>>>             be archived. Set it
>>>             ?? // to null and it will be recreated at runtime.
>>>             ?? java_lang_Class::set_reflection_data(m, nullptr);
>>>
>>>
>>>         Hi Ioi,
>>>
>>>         This patch effectively does the same thing as my initial
>>>         patch for storing classData in the scratch mirror object [1].
>>>
>>>         At this point I think it would be useful to do a quick recap
>>>         of the issues mentioned in this thread. There are 3 issues I
>>>         have encountered so far.
>>>         I was initially thinking of a solution that would cover all
>>>         these problems, but looking at these again, I feel these are
>>>         orthogonal to each other:
>>>
>>>         1. The missing classData in scratch mirrors which can be
>>>         fixed by either of the patches shared in this thread. They
>>>         achieve the same goal and I don't have any strong preference
>>>         for any of them.
>>>
>>>         2. After fixing the classData, I ran into
>>>         WrongMethodTypeException issue [2] which I fixed by
>>>         exchanging the order of indy resolution with the call to
>>>         MethodType::createArchivedObjects [3].
>>>         This change makes sense because we want to make sure all the
>>>         MethodType objects that can be archived are in
>>>         MethodType?internTable before calling
>>>         MethodType::createArchivedObjects.
>>>         I am not sure why LambdaWithUseImplMethodHandle.java didn't
>>>         throw the WrongMethodTypeException, as the Infinispan code does.
>>>
>>>         3. After fixing the WrongMethodTypeException I hit NPE due
>>>         to the class initialization cycle between
>>>         PrimitiveClassDescImpl?and ConstantDescs [4] in one of my
>>>         own testcase.
>>>         We are looking for a solution to this problem. I am not sure
>>>         if we can break this cycle by?refactoring the?Java code.
>>>         Nevertheless, I think it is fair to assume that there is no
>>>         Java code that can initiate initialization of
>>>         PrimitiveClassDescImpl beforeConstantDescs, otherwise we
>>>         would have hit the NPE earlier.
>>>         So if ConstantDescsis always expected to be initialized
>>>         before PrimitiveClassDescImpl?then I think the VM code
>>>         should also maintain this assumption.
>>>         Now this brings us back to the forceful initialization done
>>>         by the VM during the assembly phase based on the
>>>         forced_preinit_classes list in aotClassInitializer.cpp:
>>>
>>>         ? ? // TODO:
>>>         ? ? // This is needed since JDK-8338532. Without this, when
>>>         ? ? // archived heap objects are used, the class init order
>>>         is not
>>>         ? ? // expected by the jdk/internal/constant bootstrap code
>>>         and we
>>>         ? ? // will get a null pointer exception.
>>>         ? ? //
>>>         ? ? // When bootstraping has intricated/fragile order, it's
>>>         probably
>>>         ? ? // better to archive all related classes in an
>>>         initialized state
>>>         ? ? // (i.e., take a snapshot). The existing approach in
>>>         ? ? // heapShared::resolve_or_init_classes_for_subgraph_of()
>>>         won't work.
>>>         "jdk/internal/constant/PrimitiveClassDescImpl",
>>>         "jdk/internal/constant/ReferenceClassDescImpl",
>>>         ? ? "java/lang/constant/ConstantDescs",
>>>         ? ? "sun/invoke/util/Wrapper",
>>>
>>>         I wonder why we need to explicitly add
>>>         PrimitiveClassDescImpl?and ReferenceClassDescImpl?in this list.
>>>         Initialization of ConstantDescs?would anyway trigger the
>>>         initialization of PrimitiveClassDescImpl?and
>>>         ReferenceClassDescImpl.
>>>         So if we only keep the entry for ConstantDescs?and remove
>>>         PrimitiveClassDescImpl?and ReferenceClassDescImpl?from this
>>>         list,
>>>         we can be sure that the forceful initialization by the VM
>>>         would maintain the same order of initialization as guided by
>>>         the Java code,
>>>         and we will not hit the NPE when initializing
>>>         PrimitiveClassDescImpl during the assembly phase.
>>>         Does this make sense?
>>>
>>>
>>>         [1]
>>>         https://mail.openjdk.org/pipermail/leyden-dev/2024-September/000994.html
>>>         [2]
>>>         https://mail.openjdk.org/pipermail/leyden-dev/2024-September/000997.html
>>>         [3]
>>>         https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>>         <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!KvYLs_vG0a4GO3ltinXQkxBG1kMhCAvmmM6MwODoKzOhhVjzNL80S_0mBzYvYyhYPQnGmXhAXSw78Q$>
>>>         [4]
>>>         https://mail.openjdk.org/pipermail/leyden-dev/2024-September/001018.html
>>>
>>>         Thanks,
>>>         - Ashutosh Mehra
>>>
>>>
>>>         On Thu, Sep 19, 2024 at 8:51?PM <ioi.lam at oracle.com> wrote:
>>>
>>>             Upon further investigation, it seems a simple patch
>>>             might fix the problem with classData.
>>>
>>>             I tested with
>>>             test/hotspot/jtreg/runtime/cds/appcds/LambdaWithUseImplMethodHandle.java
>>>             by running jtreg with -javaoptions:-XX:+AOTClassLinking
>>>             Without the patch, I'd get a NullPointerException. With
>>>             the patch, the test passes.
>>>
>>>             It looks like classData is not treated as a static field
>>>             of the class, but rather an instance field in the
>>>             mirror. So classData wasn't copied by the loop in
>>>             HeapShared::copy_preinitialized_mirror().
>>>
>>>             Ashutosh, could you try it this fixes the crash on your
>>>             side?
>>>
>>>             Thanks
>>>
>>>             - Ioi
>>>
>>>             diff --git a/src/hotspot/share/cds/heapShared.cpp
>>>             b/src/hotspot/share/cds/heapShared.cpp
>>>             index 0e70778f057..62cf142f67a 100644
>>>             --- a/src/hotspot/share/cds/heapShared.cpp
>>>             +++ b/src/hotspot/share/cds/heapShared.cpp
>>>             @@ -634,6 +634,8 @@ void
>>>             HeapShared::copy_preinitialized_mirror(Klass* orig_k,
>>>             oop orig_mirror, oop
>>>             ???? }
>>>             ?? }
>>>
>>>             +? java_lang_Class::set_class_data(m,
>>>             java_lang_Class::class_data(orig_mirror));
>>>             +
>>>             ?? // Class::reflectData use SoftReference, which cannot
>>>             be archived. Set it
>>>             ?? // to null and it will be recreated at runtime.
>>>             ?? java_lang_Class::set_reflection_data(m, nullptr);
>>>
>>>
>>>
>>>             On 9/19/24 12:51 PM, ioi.lam at oracle.com wrote:
>>>>
>>>>
>>>>             On 9/19/24 7:44 AM, Ashutosh Mehra wrote:
>>>>>
>>>>>                 As I am cleaning up the code for upstreaming to
>>>>>                 mainline, I am going add an equivalent check in
>>>>>                 the C code to filter out these indy call sites, so
>>>>>                 they won't be resolved at all during the assembly
>>>>>                 phase. Otherwise, I will run into problems
>>>>>                 described in
>>>>>                 https://bugs.openjdk.org/browse/JDK-8290417
>>>>>
>>>>>
>>>>>             Thanks for the link to the bug. The scenario described
>>>>>             in that bug is exactly the same as the Infinispan case.
>>>>>             So if we filter out such cases during indy resolution
>>>>>             then it should resolve the Infinispan issue as well.
>>>>>
>>>>>             A basic question: why?can't CDS handle the lambda
>>>>>             proxy class generated in useImplMethodHandle?mode?
>>>>>
>>>>             If I remember correctly, it has to do with the shape of
>>>>             dynamically generated bytecode:
>>>>
>>>>             ? public void accept(java.lang.Object);
>>>>             ??? Code:
>>>>             ?????? 0: ldc #28 // Dynamic
>>>>             #0:_:Ljava/lang/invoke/MethodHandle;
>>>>             ?????? 2: aload_0
>>>>             ?????? 3: getfield #15 // Field arg$1:LTester;
>>>>             ?????? 6: aload_1
>>>>             ?????? 7: checkcast #30 // class java/lang/String
>>>>             ????? 10: invokevirtual #36 // Method
>>>>             java/lang/invoke/MethodHandle.invokeExact:(LTester;Ljava/lang/String;)V
>>>>             ????? 13: return
>>>>
>>>>             The result of the "ldc" was not symbolically encoded in
>>>>             the generated class (as the generated class has no
>>>>             permission to access that method). So the MethodHandle
>>>>             is stored as a binary object in the mirror of this
>>>>             generated class (with the java.lang.Class::classData
>>>>             field).
>>>>
>>>>             Plain CDS doesn't archive class mirrors, so the
>>>>             classData will be lost.
>>>>
>>>>             With JEP 483, we should be able to preserve the
>>>>             classData, so I am not sure why the useImplMethodHandle
>>>>             case is still failing. My plan is to filter these out
>>>>             for now, but I will get back to it later when I have
>>>>             more time.
>>>>
>>>>             Thanks
>>>>
>>>>             - Ioi
>>>>
>>>>
>>>>
>>>>
>>>>>             Thanks,
>>>>>             - Ashutosh Mehra
>>>>>
>>>>>
>>>>>             On Thu, Sep 19, 2024 at 1:45?AM <ioi.lam at oracle.com>
>>>>>             wrote:
>>>>>
>>>>>                 Hi Ashutosh,
>>>>>
>>>>>                 I have some update:
>>>>>
>>>>>                 The original crash was caused by the
>>>>>                 "useImplMethodHandle" code in
>>>>>                 InnerClassLambdaMetafactory.java:
>>>>>
>>>>>                 ??????? // If the target class invokes a protected
>>>>>                 method inherited from a
>>>>>                 ??????? // superclass in a different package, or
>>>>>                 does 'invokespecial', the
>>>>>                 ??????? // lambda class has no access to the
>>>>>                 resolved method, or does
>>>>>                 ??????? // 'invokestatic' on a hidden class which
>>>>>                 cannot be resolved by name.
>>>>>                 ??????? // Instead, we need to pass the live
>>>>>                 implementation method handle to
>>>>>                 ??????? // the proxy class to invoke directly.
>>>>>                 (javac prefers to avoid this
>>>>>                 ??????? // situation by generating bridges in the
>>>>>                 target class)
>>>>>                 ??????? useImplMethodHandle =
>>>>>                 (Modifier.isProtected(implInfo.getModifiers()) &&
>>>>>                 !VerifyAccess.isSamePackage(targetClass,
>>>>>                 implInfo.getDeclaringClass())) ||
>>>>>                 implKind == MethodHandleInfo.REF_invokeSpecial ||
>>>>>                 implKind == MethodHandleInfo.REF_invokeStatic &&
>>>>>                 implClass.isHidden();
>>>>>
>>>>>                 As I am cleaning up the code for upstreaming to
>>>>>                 mainline, I am going add an equivalent check in
>>>>>                 the C code to filter out these indy call sites, so
>>>>>                 they won't be resolved at all during the assembly
>>>>>                 phase. Otherwise, I will run into problems
>>>>>                 described in
>>>>>                 https://bugs.openjdk.org/browse/JDK-8290417
>>>>>
>>>>>                 Once I get the filtering code working, I will
>>>>>                 integrate it back to premain.
>>>>>
>>>>>                 >I am wondering if we can workaround class
>>>>>                 circularity issues by recording class
>>>>>                 initialization order
>>>>>                 >during training run and use that to guide the
>>>>>                 initialization during assembly phase.
>>>>>
>>>>>                 In the production run we take different paths than
>>>>>                 the training run
>>>>>
>>>>>                 (1) some classes are aot-initialized (especially
>>>>>                 the enums)
>>>>>                 (2) some classes make special CDS calls
>>>>>
>>>>>                 so I am not sure if it's possible to get the same
>>>>>                 initialization order as in the training run (or
>>>>>                 assembly phase).
>>>>>
>>>>>                 (more below)
>>>>>
>>>>>                 On 9/18/24 9:10 AM, Ashutosh Mehra wrote:
>>>>>>                 Hi Ioi,
>>>>>>
>>>>>>                     I was having a similar circularity issue (but
>>>>>>                     in production time) and I just added enough
>>>>>>                     classes to make the NPE go away.
>>>>>>
>>>>>>                 I am wondering if you have a test case that
>>>>>>                 reproduces the NPE which prompted you to add
>>>>>>                 these classes:
>>>>>>
>>>>>>                 https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp#L65-L78
>>>>>>                 <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/7781109154bf2af89854c7e13aa3e160bb82608e/src/hotspot/share/cds/aotClassInitializer.cpp*L65-L78__;Iw!!ACWV5N9M2RV99hQ!NYvqLbb_Ib2kSdm2fcYVLGby-AiB2TG7KtC1HQHVKLiM-_kRb5mOt8krV5IZfReaYZ0MPadDfa08hQ$>
>>>>>>
>>>>>>                 I commented this code and ran the tests under
>>>>>>                 premain but didn't hit?the NPE.
>>>>>>
>>>>>                 I forgot what the problem was, but it happened for
>>>>>                 very simple cases.
>>>>>
>>>>>                 Thanks
>>>>>
>>>>>                 - Ioi
>>>>>
>>>>>
>>>>>>                 Thanks,
>>>>>>                 - Ashutosh Mehra
>>>>>>
>>>>>>
>>>>>>                 On Tue, Sep 17, 2024 at 1:11?AM
>>>>>>                 <ioi.lam at oracle.com> wrote:
>>>>>>
>>>>>>                     Hi Ashutosh,
>>>>>>
>>>>>>                     So this looks like a potential bug (or
>>>>>>                     feature) in the core lib code. When CDS
>>>>>>                     forcefully initializes a class in an
>>>>>>                     unexpected (or untested) order, the
>>>>>>                     "initialization soup" fails.
>>>>>>
>>>>>>                     Perhaps a work-around would be to make some
>>>>>>                     harmless calls at the place where CDS was
>>>>>>                     calling into
>>>>>>                     MethodType.createArchivedObjects(). E.g., do
>>>>>>                     something like this:
>>>>>>
>>>>>>                     + if (CDSConfig::is_dumping_invokedynamic()) {
>>>>>>                     +?????? // call into Java:
>>>>>>                     jdk.internal.misc::warmupInvokeDynamic();
>>>>>>                     +?? }
>>>>>>                     ??? // Rewrite and link classes
>>>>>>                     log_info(cds)("Rewriting and linking classes
>>>>>>                     ...");
>>>>>>
>>>>>>                     Maybe you can add a new Lambda expressions,
>>>>>>                     MethodHandle invocations, etc, that would
>>>>>>                     hopefully cause PrimitiveClassDescImpl and
>>>>>>                     friends to be initialized in their natural order.
>>>>>>
>>>>>>                     Or call
>>>>>>                     class.forName("java.lang.constant.ConstantDescs")
>>>>>>                     ??
>>>>>>
>>>>>>                     BTW, you can see my comments in
>>>>>>                     AOTClassInitializer::is_forced_preinit_class():
>>>>>>
>>>>>>                     ??? // TODO:
>>>>>>                     ??? // This is needed since JDK-8338532.
>>>>>>                     Without this, when
>>>>>>                     ??? // archived heap objects are used, the
>>>>>>                     class init order is not
>>>>>>                     ??? // expected by the jdk/internal/constant
>>>>>>                     bootstrap code and we
>>>>>>                     ??? // will get a null pointer exception.
>>>>>>                     ??? //
>>>>>>                     ??? // When bootstraping has
>>>>>>                     intricated/fragile order, it's probably
>>>>>>                     ??? // better to archive all related classes
>>>>>>                     in an initialized state
>>>>>>                     ??? // (i.e., take a snapshot). The existing
>>>>>>                     approach in
>>>>>>                     ??? //
>>>>>>                     heapShared::resolve_or_init_classes_for_subgraph_of()
>>>>>>                     won't work.
>>>>>>                     "jdk/internal/constant/PrimitiveClassDescImpl",
>>>>>>                     "jdk/internal/constant/ReferenceClassDescImpl",
>>>>>>                     "java/lang/constant/ConstantDescs",
>>>>>>                     "sun/invoke/util/Wrapper",
>>>>>>
>>>>>>                     I was having a similar circularity issue (but
>>>>>>                     in production time) and I just added enough
>>>>>>                     classes to make the NPE go away. For your
>>>>>>                     test case, if you manage to fix in in the
>>>>>>                     assembly run but run into NPE in production
>>>>>>                     run, you might need to add more classes to
>>>>>>                     this list. Yes, it's a hack :-(
>>>>>>
>>>>>>
>>>>>>                     Thanks
>>>>>>
>>>>>>                     - Ioi
>>>>>>
>>>>>>                     On 9/13/24 7:05 PM, Ashutosh Mehra wrote:
>>>>>>>                     This is turning out to be a real example of
>>>>>>>                     class initialization soup!
>>>>>>>                     As mentioned during the meeting, I am
>>>>>>>                     getting NPE in the assembly phase when
>>>>>>>                     testing the patch [0] that I proposed in my
>>>>>>>                     earlier mail
>>>>>>>                     using a test case inspired by the Infinispan
>>>>>>>                     code.
>>>>>>>                     NPE occurs when running the class
>>>>>>>                     initializer for PrimitiveClassDescImpl
>>>>>>>                     Interestingly, PrimitiveClassDescImpl?is
>>>>>>>                     "forcefully" initialized by
>>>>>>>                     MetaspaceShared::link_shared_classes().
>>>>>>>
>>>>>>>                     I couldn't get a stack trace so I relied on
>>>>>>>                     exception logs (using
>>>>>>>                     -Xlog:exceptions=trace) to find the cause
>>>>>>>                     which indicate following frames on the stack:
>>>>>>>
>>>>>>>                     [0]
>>>>>>>                     jdk/internal/constant/MethodTypeDescImpl::validateArgument(Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/ClassDesc;?@
>>>>>>>                     bci 1
>>>>>>>                     [1]
>>>>>>>                     jdk/internal/constant/MethodTypeDescImpl::ofTrusted(Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljdk/internal/constant/MethodTypeDescImpl;?@
>>>>>>>                     bci 27
>>>>>>>                     [2]
>>>>>>>                     java/lang/constant/ConstantDescs::ofConstantBootstrap(Ljava/lang/constant/ClassDesc;Ljava/lang/String;Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/DirectMethodHandleDesc;?@
>>>>>>>                     bci 47
>>>>>>>                     [3]
>>>>>>>                     java/lang/constant/ConstantDescs::<clinit>?@
>>>>>>>                     bci 664
>>>>>>>                     [4]
>>>>>>>                     jdk/internal/constant/PrimitiveClassDescImpl::<init>(Ljava/lang/String;)V?@
>>>>>>>                     bci 1
>>>>>>>                     [5]
>>>>>>>                     jdk/internal/constant/PrimitiveClassDescImpl::<clinit>(Ljava/lang/String;)V?@
>>>>>>>                     bci 6
>>>>>>>
>>>>>>>                     Notice?that invocation of
>>>>>>>                     PrimitiveClassDescImpl::<clinit> results in
>>>>>>>                     initialization of ConstantDescs?class (see
>>>>>>>                     frame 3).
>>>>>>>                     ConstantDescs::<clinit>?@ 664 corresponds to
>>>>>>>                     following java code:
>>>>>>>
>>>>>>>                     ? ? public static final
>>>>>>>                     DirectMethodHandleDesc BSM_CLASS_DATA_AT
>>>>>>>                     ? ? ? ? ? ? =
>>>>>>>                     ofConstantBootstrap(CD_MethodHandles,
>>>>>>>                     "classDataAt",
>>>>>>>                     CD_Object, CD_int);
>>>>>>>
>>>>>>>                     The last parameter CD_int is initialized as:
>>>>>>>
>>>>>>>                     ? ? public static final ClassDesc CD_int =
>>>>>>>                     PrimitiveClassDescImpl.CD_int;
>>>>>>>
>>>>>>>                     So, its value is obtained from
>>>>>>>                     PrimitiveClassDescImpl.CD_int?which hasn't
>>>>>>>                     been initialized properly yet. As a result
>>>>>>>                     ConstantDescs::CD_int is assigned?null which
>>>>>>>                     results in
>>>>>>>                     MethodTypeDescImpl::validateArgument
>>>>>>>                     throwing NPE later.
>>>>>>>                     There is a clear class initialization
>>>>>>>                     circularity involving PrimitiveClassDescImpl
>>>>>>>                     and ConstantDescs, and the result depends on
>>>>>>>                     which class gets initialized first.
>>>>>>>
>>>>>>>                     Without my patch this issue is not seen
>>>>>>>                     because PrimitiveClassDescImpl has already
>>>>>>>                     been initialized by the time
>>>>>>>                     MetaspaceShared::link_shared_classes()?is
>>>>>>>                     called.
>>>>>>>                     Its initialization is triggered by the call
>>>>>>>                     to MethodType::createArchivedObjects().
>>>>>>>                     It also explains why my patch introduced
>>>>>>>                     this issue because it effectively moved the
>>>>>>>                     call to MethodType::createArchivedObjects()
>>>>>>>                     after MetaspaceShared::link_shared_classes().
>>>>>>>
>>>>>>>                     [0]
>>>>>>>                     https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>>>>>>                     <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>>>>>>
>>>>>>>                     Thanks,
>>>>>>>                     - Ashutosh Mehra
>>>>>>>
>>>>>>>
>>>>>>>                     On Wed, Sep 11, 2024 at 3:12?PM Ashutosh
>>>>>>>                     Mehra <asmehra at redhat.com> wrote:
>>>>>>>
>>>>>>>                         Regarding the WrongMethodTypeException
>>>>>>>                         that I mentioned in my previous email
>>>>>>>                         (see pt 3),
>>>>>>>                         this exception happens when lambda proxy
>>>>>>>                         class attempts to invoke the
>>>>>>>                         MethodHandle it obtained from the classData:
>>>>>>>
>>>>>>>                         ? public void accept(java.lang.Object);
>>>>>>>                         descriptor: (Ljava/lang/Object;)V
>>>>>>>                         ? ? flags: (0x0001) ACC_PUBLIC
>>>>>>>                         ? ? Code:
>>>>>>>                         ? ? ? stack=3, locals=2, args_size=2
>>>>>>>                         ? ? ? ? ?0: ldc #26 ? ? ? // Dynamic
>>>>>>>                         #0:_:Ljava/lang/invoke/MethodHandle;
>>>>>>>                         ? ? ? ? ?2: aload_0
>>>>>>>                         ? ? ? ? ?3: getfield ?#13 ? ? ? // Field
>>>>>>>                         arg$1:Lorg/wildfly/security/WildFlyElytronBaseProvider;
>>>>>>>                         ? ? ? ? ?6: aload_1
>>>>>>>                         ? ? ? ? ?7: checkcast #28 ? ? ? // class
>>>>>>>                         java/security/Provider$Service
>>>>>>>                         ? ? ? ? 10: invokevirtual #34 ? ? ? //
>>>>>>>                         Method
>>>>>>>                         java/lang/invoke/MethodHandle.invokeExact:(Lorg/wildfly/security/WildFlyElytronBaseProvider;Ljava/security/Provider$Service;)V
>>>>>>>                         ? ? ? ? 13: return
>>>>>>>
>>>>>>>                         The scenario is during the assembly
>>>>>>>                         phase as part of the indy resolution the
>>>>>>>                         MethodHandle for which the exception is
>>>>>>>                         thrown gets created.
>>>>>>>                         Normally MethodHandle's type gets added
>>>>>>>                         in MethodType::internTable but by the
>>>>>>>                         time indy resolution happens, JVM has
>>>>>>>                         already taken
>>>>>>>                         snapshot of the MethodType::internTable
>>>>>>>                         through an upcall to
>>>>>>>                         MethodType::createArchivedObjects().
>>>>>>>                         As a result the AOTCache ends up with
>>>>>>>                         the MethodType object which is not in
>>>>>>>                         AOTHolder.archivedMethodTypes.
>>>>>>>
>>>>>>>                         During the production run, when the jvm
>>>>>>>                         invokes the MethodHandle, it searches
>>>>>>>                         for the MethodType corresponding to the
>>>>>>>                         signature passed at the callsite.
>>>>>>>                         As expected, it fails to find it in the
>>>>>>>                         AOTHolder.archivedMethodTypes, so it
>>>>>>>                         creates a new instance of the MethodType.
>>>>>>>                         But Invokers.checkExactType() relies on
>>>>>>>                         the MethodHandle's?type to be the same
>>>>>>>                         object as the MethodType object passed
>>>>>>>                         as parameter.
>>>>>>>
>>>>>>>                         ? ? static void
>>>>>>>                         checkExactType(MethodHandle mhM,
>>>>>>>                         MethodType expected) {
>>>>>>>                         ? ? ? ? MethodType targetType = mh.type();
>>>>>>>                         ? ? ? ? if (targetType != expected)
>>>>>>>                         throw
>>>>>>>                         newWrongMethodTypeException(targetType,
>>>>>>>                         expected);
>>>>>>>                         ? ? }
>>>>>>>
>>>>>>>                         Hence, it throws
>>>>>>>                         WrongMethodTypeException?though the two
>>>>>>>                         MT objects have the same signature.
>>>>>>>
>>>>>>>                         To handle this scenario, I changed the
>>>>>>>                         order of indy resolution and upcall to
>>>>>>>                         MethodType::createArchivedObjects()?as:
>>>>>>>
>>>>>>>                         diff --git
>>>>>>>                         a/src/hotspot/share/cds/metaspaceShared.cpp
>>>>>>>                         b/src/hotspot/share/cds/metaspaceShared.cpp
>>>>>>>                         index df4bcadefa3..457716cac5b 100644
>>>>>>>                         ---
>>>>>>>                         a/src/hotspot/share/cds/metaspaceShared.cpp
>>>>>>>                         +++
>>>>>>>                         b/src/hotspot/share/cds/metaspaceShared.cpp
>>>>>>>                         @@ -751,6 +751,20 @@ void
>>>>>>>                         MetaspaceShared::link_shared_classes(bool
>>>>>>>                         jcmd_request, TRAPS) {
>>>>>>>                         ? ?if
>>>>>>>                         (CDSConfig::is_dumping_final_static_archive())
>>>>>>>                         {
>>>>>>>                         ?FinalImageRecipes::apply_recipes(CHECK);
>>>>>>>                         ? ?}
>>>>>>>                         +
>>>>>>>                         +#if INCLUDE_CDS_JAVA_HEAP
>>>>>>>                         + ?if
>>>>>>>                         (CDSConfig::is_dumping_invokedynamic()) {
>>>>>>>                         + ? ?// This makes sure that the
>>>>>>>                         MethodType and MethodTypeForm tables
>>>>>>>                         won't be updated
>>>>>>>                         + ? ?// concurrently when we are saving
>>>>>>>                         their contents into a side table.
>>>>>>>                         +
>>>>>>>                         ?assert(CDSConfig::allow_only_single_java_thread(),
>>>>>>>                         "Required");
>>>>>>>                         +
>>>>>>>                         + ? ?JavaValue result(T_VOID);
>>>>>>>                         + ?JavaCalls::call_static(&result,
>>>>>>>                         vmClasses::MethodType_klass(),
>>>>>>>                         + vmSymbols::createArchivedObjects(),
>>>>>>>                         + vmSymbols::void_method_signature(),
>>>>>>>                         + CHECK);
>>>>>>>                         + ?}
>>>>>>>                         +#endif
>>>>>>>                         ?}
>>>>>>>                         Note that indy resolution happens as
>>>>>>>                         part of
>>>>>>>                         FinalImageRecipes::apply_recipes(CHECK)
>>>>>>>                         which is now invoked before the upcall
>>>>>>>                         to createArchivedObjects().
>>>>>>>                         With this change I am able to run the
>>>>>>>                         application without any exceptions.
>>>>>>>                         My complete patch can be seen here:
>>>>>>>                         https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e
>>>>>>>                         <https://urldefense.com/v3/__https://github.com/ashu-mehra/leyden/commit/d8f99cce67df1c7b0f7ef8562676df438633a66e__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZK3GwoiA$>
>>>>>>>                         I will do more testing with this patch.
>>>>>>>
>>>>>>>                         @Ioi Lam <mailto:ioi.lam at oracle.com>?do
>>>>>>>                         you have any feedback on this patch.
>>>>>>>
>>>>>>>                         Thanks,
>>>>>>>                         - Ashutosh Mehra
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                         On Wed, Sep 11, 2024 at 10:14?AM
>>>>>>>                         Ashutosh Mehra <asmehra at redhat.com> wrote:
>>>>>>>
>>>>>>>                             Hi Andrew,
>>>>>>>                             Thanks for sharing the initial
>>>>>>>                             investigation.
>>>>>>>                             I have been looking into this and
>>>>>>>                             have a few of things to add to your
>>>>>>>                             analysis:
>>>>>>>
>>>>>>>                             1.? As you mentioned the classData
>>>>>>>                             for the lambda
>>>>>>>                             class?WildFlyElytronBaseProvider$$Lambda
>>>>>>>                             is null.
>>>>>>>                             The classData is stored in the
>>>>>>>                             mirror object of the InstanceKlass
>>>>>>>                             when the class is defined
>>>>>>>                             through?JVM_LookupDefineClass.
>>>>>>>                             However, when we create the scratch
>>>>>>>                             mirror object (which get stored in
>>>>>>>                             the AOT cache) the classData is not
>>>>>>>                             populated.
>>>>>>>                             See
>>>>>>>                             https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp#L1128-L1131
>>>>>>>                             <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/hotspot/share/classfile/javaClasses.cpp*L1128-L1131__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhbKjzG3gw$>
>>>>>>>
>>>>>>>                             ? Handle classData; // set to null.
>>>>>>>                             Will be reinitialized at runtime
>>>>>>>                             ? Handle mirror;
>>>>>>>                             ? Handle comp_mirror;
>>>>>>>                             allocate_mirror(k,
>>>>>>>                             /*is_scratch=*/true,
>>>>>>>                             protection_domain, classData,
>>>>>>>                             mirror, comp_mirror, CHECK);
>>>>>>>
>>>>>>>                             So this explains why the call to
>>>>>>>                             classData(caller.lookupClass())returned
>>>>>>>                             null.
>>>>>>>
>>>>>>>                             2. In the mainline there is a check
>>>>>>>                             in?InnerClassLambdaMetafactory.java
>>>>>>>                             for the particular code pattern used
>>>>>>>                             by the application.
>>>>>>>                             If this code pattern is found then
>>>>>>>                             the lambda proxy class is not
>>>>>>>                             included in the CDS archive.
>>>>>>>                             See
>>>>>>>                             https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L163-L170
>>>>>>>                             <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L163-L170__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZl2S9tQg$>
>>>>>>>                             and
>>>>>>>                             https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L246
>>>>>>>                             <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/d23b9f2d5e3523cc547337da59327ed86a6057a3/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java*L246__;Iw!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhYsI3Xx0g$>
>>>>>>>
>>>>>>>                             ? ? ? ? // If the target class
>>>>>>>                             invokes a protected method inherited
>>>>>>>                             from a
>>>>>>>                             ? ? ? ? // superclass in a different
>>>>>>>                             package, or does 'invokespecial', the
>>>>>>>                             ? ? ? ? // lambda class has no
>>>>>>>                             access to the resolved method, or does
>>>>>>>                             ? ? ? ? // 'invokestatic' on a
>>>>>>>                             hidden class which cannot be
>>>>>>>                             resolved by name.
>>>>>>>                             ? ? ? ? // Instead, we need to pass
>>>>>>>                             the live implementation method handle to
>>>>>>>                             ? ? ? ? // the proxy class to invoke
>>>>>>>                             directly. (javac prefers to avoid this
>>>>>>>                             ? ? ? ? // situation by generating
>>>>>>>                             bridges in the target class)
>>>>>>>                             useImplMethodHandle =
>>>>>>>                             (Modifier.isProtected(implInfo.getModifiers())
>>>>>>>                             &&
>>>>>>>                             ?!VerifyAccess.isSamePackage(targetClass,
>>>>>>>                             implInfo.getDeclaringClass())) ||
>>>>>>>                             ? ?implKind ==
>>>>>>>                             MethodHandleInfo.REF_invokeSpecial ||
>>>>>>>                             ? ?implKind ==
>>>>>>>                             MethodHandleInfo.REF_invokeStatic &&
>>>>>>>                             implClass.isHidden();
>>>>>>>
>>>>>>>                             In premain lambda proxy classes get
>>>>>>>                             included in the AOT cache as a
>>>>>>>                             result of indy resolution and that
>>>>>>>                             mechanism doesn't have this kind of
>>>>>>>                             check.
>>>>>>>
>>>>>>>                             3. For the null classData problem
>>>>>>>                             mentioned above, I tried to fix it
>>>>>>>                             by storing classData in the scratch
>>>>>>>                             mirror using the following patch:
>>>>>>>
>>>>>>>                             diff --git
>>>>>>>                             a/src/hotspot/share/classfile/javaClasses.cpp
>>>>>>>                             b/src/hotspot/share/classfile/javaClasses.cpp
>>>>>>>                             index bd8141adbcc..41766e98093 100644
>>>>>>>                             ---
>>>>>>>                             a/src/hotspot/share/classfile/javaClasses.cpp
>>>>>>>                             +++
>>>>>>>                             b/src/hotspot/share/classfile/javaClasses.cpp
>>>>>>>                             @@ -1094,9 +1094,9 @@ void
>>>>>>>                             java_lang_Class::create_mirror(Klass*
>>>>>>>                             k, Handle class_loader,
>>>>>>>                             ? ? ?}
>>>>>>>                             ? ? ?if (CDSConfig::is_dumping_heap()) {
>>>>>>>                             ? ? ? ?if
>>>>>>>                             (CDSConfig::is_dumping_protection_domains())
>>>>>>>                             {
>>>>>>>                             - ?create_scratch_mirror(k,
>>>>>>>                             protection_domain, CHECK);
>>>>>>>                             + ?create_scratch_mirror(k,
>>>>>>>                             protection_domain, classData, CHECK);
>>>>>>>                             ? ? ? ?} else {
>>>>>>>                             - ?create_scratch_mirror(k, Handle()
>>>>>>>                             /* null protection_domain*/, CHECK);
>>>>>>>                             + ?create_scratch_mirror(k, Handle()
>>>>>>>                             /* null protection_domain*/,
>>>>>>>                             classData, CHECK);
>>>>>>>                             ? ? ? ?}
>>>>>>>                             ? ? ?}
>>>>>>>                             ? ?} else {
>>>>>>>                             @@ -1117,7 +1117,7 @@ void
>>>>>>>                             java_lang_Class::create_mirror(Klass*
>>>>>>>                             k, Handle class_loader,
>>>>>>>                             ?// Note: we archive the "scratch
>>>>>>>                             mirror" instead of k->java_mirror(),
>>>>>>>                             because the
>>>>>>>                             ?// latter may contain
>>>>>>>                             dumptime-specific information that
>>>>>>>                             cannot be archived
>>>>>>>                             ?// (e.g., ClassLoaderData*, or
>>>>>>>                             static fields that are modified by
>>>>>>>                             Java code execution).
>>>>>>>                             -void
>>>>>>>                             java_lang_Class::create_scratch_mirror(Klass*
>>>>>>>                             k, Handle protection_domain, TRAPS) {
>>>>>>>                             +void
>>>>>>>                             java_lang_Class::create_scratch_mirror(Klass*
>>>>>>>                             k, Handle protection_domain, Handle
>>>>>>>                             classData, TRAPS) {
>>>>>>>                             ? ?if (k->class_loader() != nullptr &&
>>>>>>>                             ?k->class_loader() !=
>>>>>>>                             SystemDictionary::java_platform_loader()
>>>>>>>                             &&
>>>>>>>                             ?k->class_loader() !=
>>>>>>>                             SystemDictionary::java_system_loader())
>>>>>>>                             {
>>>>>>>                             @@ -1125,9 +1125,11 @@ void
>>>>>>>                             java_lang_Class::create_scratch_mirror(Klass*
>>>>>>>                             k, Handle protection_domain,
>>>>>>>                             ? ? ?return;
>>>>>>>                             ? ?}
>>>>>>>
>>>>>>>                             - ?Handle classData; // set to null.
>>>>>>>                             Will be reinitialized at runtime
>>>>>>>                             + ?//Handle classData; // set to
>>>>>>>                             null. Will be reinitialized at runtime
>>>>>>>                             ? ?Handle mirror;
>>>>>>>                             ? ?Handle comp_mirror;
>>>>>>>                             ?allocate_mirror(k,
>>>>>>>                             /*is_scratch=*/true,
>>>>>>>                             protection_domain, classData,
>>>>>>>                             mirror, comp_mirror, CHECK);
>>>>>>>
>>>>>>>                             ? ?if (comp_mirror() != nullptr) {
>>>>>>>                             diff --git
>>>>>>>                             a/src/hotspot/share/classfile/javaClasses.hpp
>>>>>>>                             b/src/hotspot/share/classfile/javaClasses.hpp
>>>>>>>                             index bc49a0861a7..7ec2a2556dd 100644
>>>>>>>                             ---
>>>>>>>                             a/src/hotspot/share/classfile/javaClasses.hpp
>>>>>>>                             +++
>>>>>>>                             b/src/hotspot/share/classfile/javaClasses.hpp
>>>>>>>                             @@ -263,7 +263,7 @@ class
>>>>>>>                             java_lang_Class : AllStatic {
>>>>>>>
>>>>>>>                             ? ?// Archiving
>>>>>>>                             ? ?static void
>>>>>>>                             serialize_offsets(SerializeClosure*
>>>>>>>                             f) NOT_CDS_RETURN;
>>>>>>>                             - ?static void
>>>>>>>                             create_scratch_mirror(Klass* k,
>>>>>>>                             Handle protection_domain, TRAPS)
>>>>>>>                             NOT_CDS_JAVA_HEAP_RETURN;
>>>>>>>                             + ?static void
>>>>>>>                             create_scratch_mirror(Klass* k,
>>>>>>>                             Handle protection_domain, Handle
>>>>>>>                             classData, TRAPS)
>>>>>>>                             NOT_CDS_JAVA_HEAP_RETURN;
>>>>>>>                             ? ?static bool
>>>>>>>                             restore_archived_mirror(Klass *k,
>>>>>>>                             Handle class_loader, Handle module,
>>>>>>>                             ?Handle protection_domain,
>>>>>>>                             ?TRAPS)
>>>>>>>                             NOT_CDS_JAVA_HEAP_RETURN_(false);
>>>>>>>
>>>>>>>                             But this resulted in a different
>>>>>>>                             exception:
>>>>>>>
>>>>>>>                             Exception in thread "main"
>>>>>>>                             java.lang.ExceptionInInitializerError
>>>>>>>                             at
>>>>>>>                             com.redhat.leyden.Main.main(Main.java:7)
>>>>>>>                             Caused by:
>>>>>>>                             java.lang.invoke.WrongMethodTypeException:
>>>>>>>                             handle's method type
>>>>>>>                             (WildFlyElytronBaseProvider,Service)void
>>>>>>>                             but found
>>>>>>>                             (WildFlyElytronBaseProvider,Service)void
>>>>>>>                             at
>>>>>>>                             java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:521)
>>>>>>>                             at
>>>>>>>                             java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:530)
>>>>>>>                             at
>>>>>>>                             java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
>>>>>>>                             at
>>>>>>>                             org.wildfly.security.WildFlyElytronBaseProvider$$Lambda/0x80000000c.accept(Unknown
>>>>>>>                             Source)
>>>>>>>                             at
>>>>>>>                             org.wildfly.security.WildFlyElytronBaseProvider.putMakedPasswordImplementations(WildFlyElytronBaseProvider.java:112)
>>>>>>>                             at
>>>>>>>                             org.wildfly.security.WildFlyElytronBaseProvider.putPasswordImplementations(WildFlyElytronBaseProvider.java:107)
>>>>>>>                             at
>>>>>>>                             org.wildfly.security.password.WildFlyElytronPasswordProvider.<init>(WildFlyElytronPasswordProvider.java:43)
>>>>>>>                             at
>>>>>>>                             org.wildfly.security.password.WildFlyElytronPasswordProvider.<clinit>(WildFlyElytronPasswordProvider.java:36)
>>>>>>>                             ... 1 more
>>>>>>>
>>>>>>>                             The exception message is strange
>>>>>>>                             because the handle's method type and
>>>>>>>                             the expected type are both
>>>>>>>                             symbolically the same.
>>>>>>>                             I am debugging this exception at the
>>>>>>>                             moment.
>>>>>>>                             Thanks,
>>>>>>>                             - Ashutosh Mehra
>>>>>>>
>>>>>>>
>>>>>>>                             On Wed, Sep 11, 2024 at 6:03?AM
>>>>>>>                             Andrew Dinn <adinn at redhat.com> wrote:
>>>>>>>
>>>>>>>                                 Oops, sorry, I debugged this a
>>>>>>>                                 few days ago! Correction to a
>>>>>>>                                 few details:
>>>>>>>
>>>>>>>                                 On 11/09/2024 10:39, Andrew Dinn
>>>>>>>                                 wrote:
>>>>>>>                                 > A crash due to an NPE was
>>>>>>>                                 observed in the Infinispan (Data
>>>>>>>                                 Grid) server
>>>>>>>                                 > app when deployed using the
>>>>>>>                                 Leyden EA. The crash still
>>>>>>>                                 manifests with
>>>>>>>                                 > the latest premain code. The
>>>>>>>                                 crash happens below an
>>>>>>>                                 application call
>>>>>>>                                 > which employs a method
>>>>>>>                                 reference as argument
>>>>>>>                                 >
>>>>>>>                                 >
>>>>>>>                                 putMakedPasswordImplementations(this::putService,
>>>>>>>                                 this);
>>>>>>>
>>>>>>>                                 The called method in turn calls
>>>>>>>                                 consumer.accept
>>>>>>>
>>>>>>>                                 ?consumer.accept(new
>>>>>>>                                 Service(provider,
>>>>>>>                                 PASSWORD_FACTORY_TYPE, algorithm,
>>>>>>>                                 "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>>>>>>                                 emptyList,
>>>>>>>                                 emptyMap));
>>>>>>>
>>>>>>>                                 which enters enters
>>>>>>>                                 MethodHandleNative::linkDynamicConstant()
>>>>>>>
>>>>>>>                                 > Debugging shows that the call
>>>>>>>                                 to linkDynamicConstant() returns
>>>>>>>                                 null.
>>>>>>>                                 >
>>>>>>>                                 > A simple reproducer for the
>>>>>>>                                 problem is available as a maven
>>>>>>>                                 project on
>>>>>>>                                 > github:
>>>>>>>                                 >
>>>>>>>                                 >
>>>>>>>                                 https://github.com/tristantarrant/elytron-leyden
>>>>>>>                                 <https://urldefense.com/v3/__https://github.com/tristantarrant/elytron-leyden__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhZaZr1akQ$>
>>>>>>>                                 >
>>>>>>>                                 > The ReadMe provides an
>>>>>>>                                 explanation of how to reproduce
>>>>>>>                                 the problem. I
>>>>>>>                                 > did so and the debugged to
>>>>>>>                                 find out some of the details of
>>>>>>>                                 what is
>>>>>>>                                 > happening (see below) but did
>>>>>>>                                 not fully clarify the problem.
>>>>>>>                                 Help from
>>>>>>>                                 > someone more conversant with
>>>>>>>                                 the ins and outs of method handle
>>>>>>>                                 > bootstraps in premain would be
>>>>>>>                                 welcome. Details follow.
>>>>>>>                                 >
>>>>>>>                                 > regards,
>>>>>>>                                 >
>>>>>>>                                 >
>>>>>>>                                 > Andrew Dinn
>>>>>>>                                 > -----------
>>>>>>>                                 >
>>>>>>>                                 > I downloaded the git repo and
>>>>>>>                                 attached the Java sources using
>>>>>>>                                 Maven command
>>>>>>>                                 >
>>>>>>>                                 >? ? $ mvn dependency:sources
>>>>>>>                                 >
>>>>>>>                                 > Having manifested the crash by
>>>>>>>                                 following the instructions in
>>>>>>>                                 the README
>>>>>>>                                 > I reran the leyden JVM under
>>>>>>>                                 gdb using the following commands
>>>>>>>                                 to enable
>>>>>>>                                 > Java debugging
>>>>>>>                                 >
>>>>>>>                                 > $ gdb ${LEYDEN_HOME}/bin/java
>>>>>>>                                 > (gdb) cd /path/to/mvn/project
>>>>>>>                                 > (gdb) run
>>>>>>>                                 >
>>>>>>>                                 -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
>>>>>>>
>>>>>>>                                 > -classpath
>>>>>>>                                 >
>>>>>>>                                 /home/adinn/redhat/openjdk/infinispan/elytron-leyden/base/target/elytron-leyden-base-0.0.1-SNAPSHOT.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-credential/2.5.1.
>>>>>>>                                 <https://urldefense.com/v3/__http://2.5.1.__;!!ACWV5N9M2RV99hQ!MnS3LSY2PXCCXbHvdyMfR6Nj57XH7Ey7aZuOLmQ__hhE_RhUrKnkzZ0uP8AwLZYcl8lAhhauJ-RjcQ$>Final/wildfly-elytron-credential-2.5.1.Final.jar:/home/adinn/.m2/repository/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final.jar
>>>>>>>                                 -XX:CacheDataStore=elytron.aot
>>>>>>>                                 com.redhat.leyden.Main
>>>>>>>                                 >
>>>>>>>                                 > The problem manifests at
>>>>>>>                                 WildflyElytronBaseProvider.java:112
>>>>>>>                                 in method
>>>>>>>                                 >
>>>>>>>                                 WildflyElytronBaseProvider::putMakedPasswordImplementations
>>>>>>>
>>>>>>>                                 ? ? ?static void
>>>>>>>                                 putMakedPasswordImplementations(Consumer<Service>
>>>>>>>
>>>>>>>                                 consumer, Provider provider) {
>>>>>>>                                 ? ? ? ? ?for (String algorithm :
>>>>>>>                                 MASKED_ALGORITHMS) {
>>>>>>>                                 ?consumer.accept(new
>>>>>>>                                 Service(provider,
>>>>>>>                                 PASSWORD_FACTORY_TYPE, algorithm,
>>>>>>>                                 "org.wildfly.security.password.impl.PasswordFactorySpiImpl",
>>>>>>>                                 emptyList,
>>>>>>>                                 emptyMap)); <== NPE under this call
>>>>>>>                                 ? ? ? ? ?}
>>>>>>>
>>>>>>>
>>>>>>>                                 > The source code for this
>>>>>>>                                 method can be found in the
>>>>>>>                                 following source jar
>>>>>>>                                 >
>>>>>>>                                 >
>>>>>>>                                 >
>>>>>>>                                 ${M2_REPO}/org/wildfly/security/wildfly-elytron-base/2.5.1.Final/wildfly-elytron-base-2.5.1.Final-sources.jar
>>>>>>>                                 >
>>>>>>>                                 > (where M2_REPO will normally
>>>>>>>                                 be ~/.m2/repository)
>>>>>>>                                 >
>>>>>>>                                 > Stepping into accept
>>>>>>>                                 eventually enters
>>>>>>>                                 MethodHandleNative::linkDynamicConstant
>>>>>>>
>>>>>>>                                 > which in turn enters into
>>>>>>>                                 ConstantBootstraps.makeConstant().
>>>>>>>                                 The caller
>>>>>>>                                 > Class at this point is a
>>>>>>>                                 lambda class which prints as
>>>>>>>                                 >
>>>>>>>                                 org.wildfly.security.WildflyElytronBaseProvider$$Lambda/0x800000000c
>>>>>>>                                 >
>>>>>>>                                 > Several steps further the code
>>>>>>>                                 enters
>>>>>>>                                 BootstrapMethodInvoker::invoke
>>>>>>>                                 > (below the app method call but
>>>>>>>                                 via 3 hidden frames) with
>>>>>>>                                 bootstrapMethod
>>>>>>>                                 > bound to a DirectMethodHandle.
>>>>>>>                                 After several more steps this
>>>>>>>                                 enters
>>>>>>>                                 >
>>>>>>>                                 DirectMethodHandle$Holder.invokeStatic
>>>>>>>                                 which in turn calls
>>>>>>>                                 >
>>>>>>>                                 MethodHandles::classData(Lookup,String,Class).
>>>>>>>                                 >
>>>>>>>                                 > At this point caller is a
>>>>>>>                                 MethodHandleLookup for the
>>>>>>>                                 lambda class
>>>>>>>                                 > Lambda/0x800000000c mentioned
>>>>>>>                                 above. The following call
>>>>>>>                                 >
>>>>>>>                                 > Object classdata =
>>>>>>>                                 classData(caller.lookupClass());
>>>>>>>                                 >
>>>>>>>                                 > returns null to
>>>>>>>                                 DirectMethodHandle$Holder.invokeStatic
>>>>>>>                                 which pops the
>>>>>>>                                 > same result back out to
>>>>>>>                                 BootstrapMethodInvoker::invoke
>>>>>>>                                 at line 90
>>>>>>>                                 >
>>>>>>>                                 > if (type instanceof Class<?> c) {
>>>>>>>                                 > result =
>>>>>>>                                 bootstrapMethod.invoke(caller,
>>>>>>>                                 name, c);
>>>>>>>                                 > <== null
>>>>>>>                                 >
>>>>>>>                                 > This null result pops back out
>>>>>>>                                 as the value for the call to
>>>>>>>                                 >
>>>>>>>                                 BootstrapMethodInvoker.invoke(),
>>>>>>>                                 ConstantBootstraps.makeConstant()
>>>>>>>                                 and
>>>>>>>                                 >
>>>>>>>                                 MethodHandleNative::linkDynamicConstant().
>>>>>>>                                 >
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240925/13a1cbac/attachment.htm>

From ioi.lam at oracle.com  Wed Sep 25 17:07:46 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Wed, 25 Sep 2024 10:07:46 -0700
Subject: RFR: 8293336 - AOT-linking of invokedynamic for lambda expression and
 string concat
Message-ID: <2538b3e6-f1d6-463f-9e33-8958ffdb160d@oracle.com>

Hi, this is the 7th and final PR for JEP 483 - Ahead-of-Time Class 
Loading & Linking [1].

The PR is https://github.com/openjdk/jdk/pull/21143

The reason for including this in JEP 483 is to demonstrate the start-up 
benefit of optimizations that required the stable class pointers 
provided by -XX:+AOTClassLinking. We hope to implement more 
optimizations (such as AOT-compiled methods) in future JEPs and RFEs.

Please see the PR description for a discussion of the "rough edges" 
related to object identity, which will require more research in the 
Leyden project to find a cleaner, general solution.

See? [2] for the other PRs that are also under review for JEP 483.

Thanks

- Ioi

===

[1] https://openjdk.org/jeps/483
[2] https://bugs.openjdk.org/browse/JDK-8331497


From macarte at openjdk.org  Wed Sep 25 19:59:55 2024
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 25 Sep 2024 19:59:55 GMT
Subject: RFR: 8335358: [premain] Explore alternative ways to trigger the
 end of training run [v10]
In-Reply-To: <vhDl3dIKAqKXxNft6BjKVblzbwFlF2Nvp0stOtYGhxo=.21cfe2d5-e0a8-4eb5-bb3b-7e16256b0d75@github.com>
References: <RqVNoxdgqloUtbXxgiiqePA6XRrHkuolETkbzmzr7r4=.2b32af0e-69fa-48cf-89aa-322371ef9fb2@github.com>
 <vhDl3dIKAqKXxNft6BjKVblzbwFlF2Nvp0stOtYGhxo=.21cfe2d5-e0a8-4eb5-bb3b-7e16256b0d75@github.com>
Message-ID: <0G6kI-DmQtoirBXHbAgqmetlhG8TQ9Etg2KmgI5-bpU=.c922b764-d11d-4982-8d70-26f2ca23abf7@github.com>

On Thu, 19 Sep 2024 22:25:20 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> AOT training can be ended using either
>> 
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod [same syntax as CompileOnly]
>> - -XX: AOTEndTrainingOnMethodEntry =Hello.someMethod,Hello.someOtherMethod,count=42
>> - jcmd <pid> AOT.end_training
>> 
>> supports arm64 and x64
>> 
>> note: the AOTEndTrainingOnMethodEntry is ignored when CDSPreImage is specified; this is needed as the phase2 forked java process is passed all phase1 flags along with the -XX:CDSPreImage, but we don't want to run the trigger code in this phase (there may be a better way to handle this state or simply remove the flag from the forked process)
>> 
>> JBS Issue: https://bugs.openjdk.org/browse/JDK-8335358
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove trailing spaces

Moving this PR to draft while we refactor the code as suggested

-------------

PR Comment: https://git.openjdk.org/leyden/pull/21#issuecomment-2375135170

From duke at openjdk.org  Thu Sep 26 01:50:30 2024
From: duke at openjdk.org (duke)
Date: Thu, 26 Sep 2024 01:50:30 GMT
Subject: git: openjdk/leyden: premain: Sync some files with latest JEP 483 PRs
Message-ID: <2c2096a5-7cfa-40d4-929f-2b2e5de2c161@openjdk.org>

Changeset: 5bd0b880
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-09-25 18:47:52 +0000
URL:       https://git.openjdk.org/leyden/commit/5bd0b880a78b9ad1a9d6cc9187d96e726e6c98fd

Sync some files with latest JEP 483 PRs

! src/hotspot/share/cds/aotConstantPoolResolver.cpp
! src/hotspot/share/cds/aotConstantPoolResolver.hpp
! src/hotspot/share/cds/dynamicArchive.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/classfile/systemDictionaryShared.hpp
! test/hotspot/jtreg/TEST.groups
! test/hotspot/jtreg/runtime/cds/appcds/indy/IndyMiscTests.java
! test/hotspot/jtreg/runtime/cds/appcds/resolvedConstants/ResolvedConstants.java
+ test/hotspot/jtreg/runtime/cds/appcds/test-classes/OldConsumer.jasm


From aph at openjdk.org  Thu Sep 26 08:48:56 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 26 Sep 2024 08:48:56 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v4]
In-Reply-To: <_p2-w-OWX8jH2O90d5IyoesFGlfconxRy7TU28mOKZo=.d60c7b86-ed0e-4049-ac82-5dc0eced8fc0@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
 <_p2-w-OWX8jH2O90d5IyoesFGlfconxRy7TU28mOKZo=.d60c7b86-ed0e-4049-ac82-5dc0eced8fc0@github.com>
Message-ID: <tf-HtqIBIRYgd3crAeNkZAS4D_xYK3nmWlvIQsK6-cg=.5362fd12-a6cd-4058-b986-e2a0c3d2314a@github.com>

On Wed, 25 Sep 2024 13:58:15 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> This PR modifies AOT compiled method code to load compressed oops base and shift constants via the AOTRuntimeConstants area rather than encode them as immediates. It also unlatches the currently forced setting of UseCompatibleCompressedOops, allowing the heap to be allocated wherever it will fit.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix oop decode not to side-effect flags

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5130:

> 5128:     }
> 5129:   }
> 5130:   return tmp;

Suggestion:

  auto tmps = RegSet::of(r0, r1, r2) - RegSet::of(src, dest);
  return tmps.first();

Use the force, Luke Skywalker.

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/20#discussion_r1776647545

From adinn at openjdk.org  Thu Sep 26 10:48:51 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 26 Sep 2024 10:48:51 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v4]
In-Reply-To: <tf-HtqIBIRYgd3crAeNkZAS4D_xYK3nmWlvIQsK6-cg=.5362fd12-a6cd-4058-b986-e2a0c3d2314a@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
 <_p2-w-OWX8jH2O90d5IyoesFGlfconxRy7TU28mOKZo=.d60c7b86-ed0e-4049-ac82-5dc0eced8fc0@github.com>
 <tf-HtqIBIRYgd3crAeNkZAS4D_xYK3nmWlvIQsK6-cg=.5362fd12-a6cd-4058-b986-e2a0c3d2314a@github.com>
Message-ID: <FdKhnE0j2ChQzztz0ELoiN-3PiGU4OcSmp4jlH0vJM0=.ce9f28b2-d4fa-4adb-ae46-3cb6d5f76a56@github.com>

On Thu, 26 Sep 2024 08:46:25 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix oop decode not to side-effect flags
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5130:
> 
>> 5128:     }
>> 5129:   }
>> 5130:   return tmp;
> 
> Suggestion:
> 
>   auto tmps = RegSet::of(r0, r1, r2) - RegSet::of(src, dest);
>   return tmps.first();
> 
> Use the force, Luke Skywalker.

A-and ... this version actually works:

    auto tmps = RegSet::of(r0, r1, r2) - RegSet::of(src, dst);
    return *tmps.begin();

(`first()` is private :-)

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/20#discussion_r1776820677

From adinn at openjdk.org  Thu Sep 26 10:52:02 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 26 Sep 2024 10:52:02 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v5]
In-Reply-To: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
Message-ID: <ew48NMQpOPxwoWEHMWb6UTASfO-fLKlBXF2VKO0HKJ0=.735016c4-3842-434e-bb1e-58555a250b3a@github.com>

> This PR modifies AOT compiled method code to load compressed oops base and shift constants via the AOTRuntimeConstants area rather than encode them as immediates. It also unlatches the currently forced setting of UseCompatibleCompressedOops, allowing the heap to be allocated wherever it will fit.

Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:

  Use the force to wrangle register sets

-------------

Changes:
  - all: https://git.openjdk.org/leyden/pull/20/files
  - new: https://git.openjdk.org/leyden/pull/20/files/7ba14a6e..067dd5d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=leyden&pr=20&range=04
 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=20&range=03-04

  Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/leyden/pull/20.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/20/head:pull/20

PR: https://git.openjdk.org/leyden/pull/20

From adinn at openjdk.org  Thu Sep 26 13:27:50 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 26 Sep 2024 13:27:50 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v5]
In-Reply-To: <ew48NMQpOPxwoWEHMWb6UTASfO-fLKlBXF2VKO0HKJ0=.735016c4-3842-434e-bb1e-58555a250b3a@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
 <ew48NMQpOPxwoWEHMWb6UTASfO-fLKlBXF2VKO0HKJ0=.735016c4-3842-434e-bb1e-58555a250b3a@github.com>
Message-ID: <VOLxLqJ-VqwbAz5X3qZjdMra8zVZa5Ilil47KKnrPrU=.be730f4c-e370-4472-a334-b26221be0ed6@github.com>

On Thu, 26 Sep 2024 10:52:02 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> This PR modifies AOT compiled method code to load compressed oops base and shift constants via the AOTRuntimeConstants area rather than encode them as immediates. It also unlatches the currently forced setting of UseCompatibleCompressedOops, allowing the heap to be allocated wherever it will fit.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the force to wrangle register sets

I tested any effects on performance by running the javac new workflow benchmark on my Linux/M2(aarch64) release build. Each timing is an average over 10 runs with runs for the different cases interleaved to amortize variation thanks to external factors. I ran the benchmark 3 times and found that the timings were not very consistent, leaving little room to pin anything down to the patch.

jvm1 = without coops
jvm2 = with coops patch

Run 1:
    ============================== jvm1 ============================
    [1_xoff] Premain JDK (CDS disabled)                    261.08 ms
    [1_xon ] Premain JDK (CDS enabled)                     144.01 ms
    [1_td  ] Premain Prototype (CDS + Training Data)       127.42 ms
    [1_aot ] Premain Prototype (CDS + Training Data + AOT)  78.80 ms
    ============================== jvm2 ============================
    [2_xoff] Premain JDK (CDS disabled)                    256.45 ms
    [2_xon ] Premain JDK (CDS enabled)                     145.14 ms
    [2_td  ] Premain Prototype (CDS + Training Data)       125.20 ms
    [2_aot ] Premain Prototype (CDS + Training Data + AOT)  80.53 ms
    ================================================================

Run 2:
    ============================== jvm1 ============================
    [1_xoff] Premain JDK (CDS disabled)                    261.16 ms
    [1_xon ] Premain JDK (CDS enabled)                     149.71 ms
    [1_td  ] Premain Prototype (CDS + Training Data)       134.25 ms
    [1_aot ] Premain Prototype (CDS + Training Data + AOT)  84.16 ms
    ============================== jvm2 ============================
    [2_xoff] Premain JDK (CDS disabled)                    262.24 ms
    [2_xon ] Premain JDK (CDS enabled)                     160.62 ms
    [2_td  ] Premain Prototype (CDS + Training Data)       134.09 ms
    [2_aot ] Premain Prototype (CDS + Training Data + AOT)  85.02 ms
    ================================================================

Run 3:
    ============================== jvm1 ============================
    [1_xoff] Premain JDK (CDS disabled)                    266.63 ms
    [1_xon ] Premain JDK (CDS enabled)                     152.51 ms
    [1_td  ] Premain Prototype (CDS + Training Data)       131.13 ms
    [1_aot ] Premain Prototype (CDS + Training Data + AOT)  89.70 ms
    ============================== jvm2 ============================
    [2_xoff] Premain JDK (CDS disabled)                    257.33 ms
    [2_xon ] Premain JDK (CDS enabled)                     147.52 ms
    [2_td  ] Premain Prototype (CDS + Training Data)       128.13 ms
    [2_aot ] Premain Prototype (CDS + Training Data + AOT)  86.08 ms
    ================================================================

This is running on bare metal with 64GB of RAM. So, the heap is allocated at 0x400000000 in boh jvm1 and jvm2 i.e. non-AOT code uses a zero base with shift 3. Only the 2_aot case can be affected by the patch but there is no noticeable difference wrt to 1_aot modulo the existing variation in results.

I reran with -Xms24M, allowing jvm2 to allocate the heap in low memory i.e. with zero for both shift and base (jvm1 still is still forced to allocate at an address > 4GB and use a shift). If anything this could only improve performance for all jvm2 cases relative to jvm1 (but less so for the 2_aot case).

Run 1:
    ============================== jvm1 ============================
    [1_xoff] Premain JDK (CDS disabled)                    273.05 ms
    [1_xon ] Premain JDK (CDS enabled)                     148.72 ms
    [1_td  ] Premain Prototype (CDS + Training Data)       131.19 ms
    [1_aot ] Premain Prototype (CDS + Training Data + AOT)  80.10 ms
    ============================== jvm2 ============================
    [2_xoff] Premain JDK (CDS disabled)                    264.14 ms
    [2_xon ] Premain JDK (CDS enabled)                     159.66 ms
    [2_td  ] Premain Prototype (CDS + Training Data)       124.52 ms
    [2_aot ] Premain Prototype (CDS + Training Data + AOT)  75.03 ms
    ================================================================

Run 2:
    ============================== jvm1 ============================
    [1_xoff] Premain JDK (CDS disabled)                    267.48 ms
    [1_xon ] Premain JDK (CDS enabled)                     163.18 ms
    [1_td  ] Premain Prototype (CDS + Training Data)       136.67 ms
    [1_aot ] Premain Prototype (CDS + Training Data + AOT)  86.41 ms
    ============================== jvm2 ============================
    [2_xoff] Premain JDK (CDS disabled)                    268.73 ms
    [2_xon ] Premain JDK (CDS enabled)                     157.70 ms
    [2_td  ] Premain Prototype (CDS + Training Data)       136.69 ms
    [2_aot ] Premain Prototype (CDS + Training Data + AOT)  90.39 ms
    ================================================================

Run 3:
    ============================== jvm1 ============================
    [1_xoff] Premain JDK (CDS disabled)                    268.36 ms
    [1_xon ] Premain JDK (CDS enabled)                     161.01 ms
    [1_td  ] Premain Prototype (CDS + Training Data)       134.43 ms
    [1_aot ] Premain Prototype (CDS + Training Data + AOT)  91.79 ms
    ============================== jvm2 ============================
    [2_xoff] Premain JDK (CDS disabled)                    260.27 ms
    [2_xon ] Premain JDK (CDS enabled)                     165.10 ms
    [2_td  ] Premain Prototype (CDS + Training Data)       138.31 ms
    [2_aot ] Premain Prototype (CDS + Training Data + AOT)  88.61 ms
    ================================================================

Once again there is no noticeable difference modulo the existing variation.

The results are not very convincing given the varying timings. However, as a tentative conclusion we can say:

1) The patch incurs no measurable loss in performance when the JVM is force to use same coops mode
2) The patch does not enable any measurable gain in performance by allowing the  JVM is force to use a more efficient coops mode.

So, I think we can drop this patch and stick with enforcing a compatible oops mode.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/20#issuecomment-2376969818

From adinn at openjdk.org  Thu Sep 26 13:42:54 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 26 Sep 2024 13:42:54 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v5]
In-Reply-To: <ew48NMQpOPxwoWEHMWb6UTASfO-fLKlBXF2VKO0HKJ0=.735016c4-3842-434e-bb1e-58555a250b3a@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
 <ew48NMQpOPxwoWEHMWb6UTASfO-fLKlBXF2VKO0HKJ0=.735016c4-3842-434e-bb1e-58555a250b3a@github.com>
Message-ID: <8b0l53u1g6wWsVnBBwLO9b6bcqrvEgz_IK403IpQrCk=.6b0459d2-d88a-40fe-bf60-25acbc75f7fb@github.com>

On Thu, 26 Sep 2024 10:52:02 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> This PR modifies AOT compiled method code to load compressed oops base and shift constants via the AOTRuntimeConstants area rather than encode them as immediates. It also unlatches the currently forced setting of UseCompatibleCompressedOops, allowing the heap to be allocated wherever it will fit.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the force to wrangle register sets

Ah, ignore those results -- I had not configured the correct task set so it was mixing big and little CPUs. I'll repost corrected results.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/20#issuecomment-2377008479

From adinn at openjdk.org  Thu Sep 26 14:06:07 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 26 Sep 2024 14:06:07 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v5]
In-Reply-To: <ew48NMQpOPxwoWEHMWb6UTASfO-fLKlBXF2VKO0HKJ0=.735016c4-3842-434e-bb1e-58555a250b3a@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
 <ew48NMQpOPxwoWEHMWb6UTASfO-fLKlBXF2VKO0HKJ0=.735016c4-3842-434e-bb1e-58555a250b3a@github.com>
Message-ID: <J12IU23IeXrzGsnGWsnxBU8Y_uVvT73bobI99_fDbqA=.db23ceed-812f-4117-88c3-ffb455458c81@github.com>

On Thu, 26 Sep 2024 10:52:02 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> This PR modifies AOT compiled method code to load compressed oops base and shift constants via the AOTRuntimeConstants area rather than encode them as immediates. It also unlatches the currently forced setting of UseCompatibleCompressedOops, allowing the heap to be allocated wherever it will fit.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the force to wrangle register sets

Ok, so here are the proper results, first when the heap is defaulted:

Run 1:

    ============================== jvm1 ============================
    [1_xoff] Premain JDK (CDS disabled)                    235.10 ms
    [1_xon ] Premain JDK (CDS enabled)                     111.21 ms
    [1_td  ] Premain Prototype (CDS + Training Data)       109.45 ms
    [1_aot ] Premain Prototype (CDS + Training Data + AOT)  56.87 ms
    ============================== jvm2 ============================
    [2_xoff] Premain JDK (CDS disabled)                    233.21 ms
    [2_xon ] Premain JDK (CDS enabled)                     111.37 ms
    [2_td  ] Premain Prototype (CDS + Training Data)       107.96 ms
    [2_aot ] Premain Prototype (CDS + Training Data + AOT)  59.00 ms
    ================================================================

Run 2:

    ============================== jvm1 ============================
    [1_xoff] Premain JDK (CDS disabled)                    235.84 ms
    [1_xon ] Premain JDK (CDS enabled)                     112.28 ms
    [1_td  ] Premain Prototype (CDS + Training Data)       108.45 ms
    [1_aot ] Premain Prototype (CDS + Training Data + AOT)  57.76 ms
    ============================== jvm2 ============================
    [2_xoff] Premain JDK (CDS disabled)                    236.09 ms
    [2_xon ] Premain JDK (CDS enabled)                     111.91 ms
    [2_td  ] Premain Prototype (CDS + Training Data)       108.86 ms
    [2_aot ] Premain Prototype (CDS + Training Data + AOT)  59.80 ms
    ================================================================


Run 3:


    ============================== jvm1 ============================
    [1_xoff] Premain JDK (CDS disabled)                    231.32 ms
    [1_xon ] Premain JDK (CDS enabled)                     111.47 ms
    [1_td  ] Premain Prototype (CDS + Training Data)       108.92 ms
    [1_aot ] Premain Prototype (CDS + Training Data + AOT)  56.26 ms
    ============================== jvm2 ============================
    [2_xoff] Premain JDK (CDS disabled)                    233.96 ms
    [2_xon ] Premain JDK (CDS enabled)                     114.21 ms
    [2_td  ] Premain Prototype (CDS + Training Data)       107.92 ms
    [2_aot ] Premain Prototype (CDS + Training Data + AOT)  60.01 ms
    ================================================================

Now the results when heap size is set to 24Mb:

Run 1:

    ============================== jvm1 ============================
    [1_xoff] Premain JDK (CDS disabled)                    237.26 ms
    [1_xon ] Premain JDK (CDS enabled)                     114.10 ms
    [1_td  ] Premain Prototype (CDS + Training Data)       108.43 ms
    [1_aot ] Premain Prototype (CDS + Training Data + AOT)  56.43 ms
    ============================== jvm2 ============================
    [2_xoff] Premain JDK (CDS disabled)                    238.70 ms
    [2_xon ] Premain JDK (CDS enabled)                     115.12 ms
    [2_td  ] Premain Prototype (CDS + Training Data)       107.67 ms
    [2_aot ] Premain Prototype (CDS + Training Data + AOT)  58.27 ms
    ================================================================

Run 2:

    ============================== jvm1 ============================
    [1_xoff] Premain JDK (CDS disabled)                    237.81 ms
    [1_xon ] Premain JDK (CDS enabled)                     114.76 ms
    [1_td  ] Premain Prototype (CDS + Training Data)       107.24 ms
    [1_aot ] Premain Prototype (CDS + Training Data + AOT)  56.57 ms
    ============================== jvm2 ============================
    [2_xoff] Premain JDK (CDS disabled)                    237.65 ms
    [2_xon ] Premain JDK (CDS enabled)                     115.34 ms
    [2_td  ] Premain Prototype (CDS + Training Data)       107.66 ms
    [2_aot ] Premain Prototype (CDS + Training Data + AOT)  59.39 ms
    ================================================================

Run 3:

    ============================== jvm1 ============================
    [1_xoff] Premain JDK (CDS disabled)                    238.08 ms
    [1_xon ] Premain JDK (CDS enabled)                     114.87 ms
    [1_td  ] Premain Prototype (CDS + Training Data)       107.35 ms
    [1_aot ] Premain Prototype (CDS + Training Data + AOT)  56.20 ms
    ============================== jvm2 ============================
    [2_xoff] Premain JDK (CDS disabled)                    237.19 ms
    [2_xon ] Premain JDK (CDS enabled)                     114.43 ms
    [2_td  ] Premain Prototype (CDS + Training Data)       107.40 ms
    [2_aot ] Premain Prototype (CDS + Training Data + AOT)  58.24 ms
    ================================================================

So, there is stil some variability in the timings which makes it hard to gauge the full effect. However, it looks as if the patch is adding at least 3% overhead to the run times for the aot case with the default heap and also with the smaller heap. The ability to vary the coops model with a smaller heap does not appear to win anything back ineither the aot case or the non-aot case.

So, we definitely drop this patch.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/20#issuecomment-2377067807

From kvn at openjdk.org  Thu Sep 26 16:21:03 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 26 Sep 2024 16:21:03 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v5]
In-Reply-To: <J12IU23IeXrzGsnGWsnxBU8Y_uVvT73bobI99_fDbqA=.db23ceed-812f-4117-88c3-ffb455458c81@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
 <ew48NMQpOPxwoWEHMWb6UTASfO-fLKlBXF2VKO0HKJ0=.735016c4-3842-434e-bb1e-58555a250b3a@github.com>
 <J12IU23IeXrzGsnGWsnxBU8Y_uVvT73bobI99_fDbqA=.db23ceed-812f-4117-88c3-ffb455458c81@github.com>
Message-ID: <3X4geD5uXCT4ZdrxLG4nrUzCDgzB11EVJSBRlNZbG-Q=.a3ae5e75-bc9d-4f15-9538-eea69acfb8e7@github.com>

On Thu, 26 Sep 2024 14:02:11 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use the force to wrangle register sets
>
> Ok, so here are the proper results, first when the heap is defaulted:
> 
> Run 1:
> 
>     ============================== jvm1 ============================
>     [1_xoff] Premain JDK (CDS disabled)                    235.10 ms
>     [1_xon ] Premain JDK (CDS enabled)                     111.21 ms
>     [1_td  ] Premain Prototype (CDS + Training Data)       109.45 ms
>     [1_aot ] Premain Prototype (CDS + Training Data + AOT)  56.87 ms
>     ============================== jvm2 ============================
>     [2_xoff] Premain JDK (CDS disabled)                    233.21 ms
>     [2_xon ] Premain JDK (CDS enabled)                     111.37 ms
>     [2_td  ] Premain Prototype (CDS + Training Data)       107.96 ms
>     [2_aot ] Premain Prototype (CDS + Training Data + AOT)  59.00 ms
>     ================================================================
> 
> Run 2:
> 
>     ============================== jvm1 ============================
>     [1_xoff] Premain JDK (CDS disabled)                    235.84 ms
>     [1_xon ] Premain JDK (CDS enabled)                     112.28 ms
>     [1_td  ] Premain Prototype (CDS + Training Data)       108.45 ms
>     [1_aot ] Premain Prototype (CDS + Training Data + AOT)  57.76 ms
>     ============================== jvm2 ============================
>     [2_xoff] Premain JDK (CDS disabled)                    236.09 ms
>     [2_xon ] Premain JDK (CDS enabled)                     111.91 ms
>     [2_td  ] Premain Prototype (CDS + Training Data)       108.86 ms
>     [2_aot ] Premain Prototype (CDS + Training Data + AOT)  59.80 ms
>     ================================================================
> 
> 
> Run 3:
> 
> 
>     ============================== jvm1 ============================
>     [1_xoff] Premain JDK (CDS disabled)                    231.32 ms
>     [1_xon ] Premain JDK (CDS enabled)                     111.47 ms
>     [1_td  ] Premain Prototype (CDS + Training Data)       108.92 ms
>     [1_aot ] Premain Prototype (CDS + Training Data + AOT)  56.26 ms
>     ============================== jvm2 ============================
>     [2_xoff] Premain JDK (CDS disabled)                    233.96 ms
>     [2_xon ] Premain JDK (CDS enabled)                     114.21 ms
>     [2_td  ] Premain Prototype (CDS + Training Data)       107.92 ms
>     [2_aot ] Premain Prototype (CDS + Training Data + AOT)  60.01 ms
>     ================================================================
> 
> Now the results when heap size is set to 24Mb:
> 
> Run 1:
> 
>     ============================== jvm1 ===========================...

Thank you @adinn for testing changes.

> So, we definitely drop this patch.

Agree.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/20#issuecomment-2377406348

From asmehra at openjdk.org  Thu Sep 26 17:13:52 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 26 Sep 2024 17:13:52 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v5]
In-Reply-To: <J12IU23IeXrzGsnGWsnxBU8Y_uVvT73bobI99_fDbqA=.db23ceed-812f-4117-88c3-ffb455458c81@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
 <ew48NMQpOPxwoWEHMWb6UTASfO-fLKlBXF2VKO0HKJ0=.735016c4-3842-434e-bb1e-58555a250b3a@github.com>
 <J12IU23IeXrzGsnGWsnxBU8Y_uVvT73bobI99_fDbqA=.db23ceed-812f-4117-88c3-ffb455458c81@github.com>
Message-ID: <JYJH6gwIgA9F3JLiJLyU2I6epD2HRL93YSGwXSY3Y6s=.0e01c0c1-295f-47e8-a3e0-2e434ea3a90e@github.com>

On Thu, 26 Sep 2024 14:02:11 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use the force to wrangle register sets
>
> Ok, so here are the proper results, first when the heap is defaulted:
> 
> Run 1:
> 
>     ============================== jvm1 ============================
>     [1_xoff] Premain JDK (CDS disabled)                    235.10 ms
>     [1_xon ] Premain JDK (CDS enabled)                     111.21 ms
>     [1_td  ] Premain Prototype (CDS + Training Data)       109.45 ms
>     [1_aot ] Premain Prototype (CDS + Training Data + AOT)  56.87 ms
>     ============================== jvm2 ============================
>     [2_xoff] Premain JDK (CDS disabled)                    233.21 ms
>     [2_xon ] Premain JDK (CDS enabled)                     111.37 ms
>     [2_td  ] Premain Prototype (CDS + Training Data)       107.96 ms
>     [2_aot ] Premain Prototype (CDS + Training Data + AOT)  59.00 ms
>     ================================================================
> 
> Run 2:
> 
>     ============================== jvm1 ============================
>     [1_xoff] Premain JDK (CDS disabled)                    235.84 ms
>     [1_xon ] Premain JDK (CDS enabled)                     112.28 ms
>     [1_td  ] Premain Prototype (CDS + Training Data)       108.45 ms
>     [1_aot ] Premain Prototype (CDS + Training Data + AOT)  57.76 ms
>     ============================== jvm2 ============================
>     [2_xoff] Premain JDK (CDS disabled)                    236.09 ms
>     [2_xon ] Premain JDK (CDS enabled)                     111.91 ms
>     [2_td  ] Premain Prototype (CDS + Training Data)       108.86 ms
>     [2_aot ] Premain Prototype (CDS + Training Data + AOT)  59.80 ms
>     ================================================================
> 
> 
> Run 3:
> 
> 
>     ============================== jvm1 ============================
>     [1_xoff] Premain JDK (CDS disabled)                    231.32 ms
>     [1_xon ] Premain JDK (CDS enabled)                     111.47 ms
>     [1_td  ] Premain Prototype (CDS + Training Data)       108.92 ms
>     [1_aot ] Premain Prototype (CDS + Training Data + AOT)  56.26 ms
>     ============================== jvm2 ============================
>     [2_xoff] Premain JDK (CDS disabled)                    233.96 ms
>     [2_xon ] Premain JDK (CDS enabled)                     114.21 ms
>     [2_td  ] Premain Prototype (CDS + Training Data)       107.92 ms
>     [2_aot ] Premain Prototype (CDS + Training Data + AOT)  60.01 ms
>     ================================================================
> 
> Now the results when heap size is set to 24Mb:
> 
> Run 1:
> 
>     ============================== jvm1 ===========================...

@adinn @vnkozlov We should also consider the fact that, as the things stand, forcing the JIT compiled methods to always use shift and fixed base could have an impact on the peak throughput. Do we have numbers how much is the peak throughput impacted? If it does then we need to decide what do we let go - startup or the peak throughput?

-------------

PR Comment: https://git.openjdk.org/leyden/pull/20#issuecomment-2377502837

From duke at openjdk.org  Thu Sep 26 20:28:54 2024
From: duke at openjdk.org (duke)
Date: Thu, 26 Sep 2024 20:28:54 GMT
Subject: git: openjdk/leyden: premain: 428 new changesets
Message-ID: <5d2cf248-37f2-4973-966b-8354f7ef835c@openjdk.org>

Changeset: 173fb74c
Branch: premain
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Committer: iklam <ilam3388 at gmail.com>
Date:      2024-08-29 21:06:05 +0000
URL:       https://git.openjdk.org/leyden/commit/173fb74c1fb476f9e0891dcce4c275ec46304b24

8339020: Remove unused HeapShared::calculate_oopmap

Reviewed-by: coleenp

! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/heapShared.hpp

Changeset: 618907c4
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Committer: iklam <ilam3388 at gmail.com>
Date:      2024-09-02 17:57:02 +0000
URL:       https://git.openjdk.org/leyden/commit/618907c438e689756a463a79357c103734da6599

8339351: Remove duplicate line in FileMapHeader::print

Reviewed-by: dholmes

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

Changeset: e9521b21
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: iklam <ilam3388 at gmail.com>
Date:      2024-09-25 21:52:12 +0000
URL:       https://git.openjdk.org/leyden/commit/e9521b217145dad7754ac3748912f5c0f88549c7

8338912: CDS: Segmented roots array

Reviewed-by: ccheung, iklam

! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/archiveHeapLoader.cpp
! src/hotspot/share/cds/archiveHeapWriter.cpp
! src/hotspot/share/cds/archiveHeapWriter.hpp
! src/hotspot/share/cds/archiveUtils.cpp
! src/hotspot/share/cds/archiveUtils.hpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/filemap.hpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/heapShared.hpp
! src/hotspot/share/cds/metaspaceShared.cpp

Changeset: ea337098
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-08-23 02:35:48 +0000
URL:       https://git.openjdk.org/leyden/commit/ea3370982bfd3da4b200b738dd3b8c16cebb3a34

8328880: Events::log_exception should limit the size of the logging message

Reviewed-by: shade, kvn

! src/hotspot/share/utilities/events.cpp
! src/hotspot/share/utilities/events.hpp
! src/hotspot/share/utilities/exceptions.cpp

Changeset: e06652ad
Branch: premain
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2024-08-23 05:47:29 +0000
URL:       https://git.openjdk.org/leyden/commit/e06652ad3c02dfe54104eaa04eaa3d117699b27f

8338810: PPC, s390x: LightweightSynchronizer::exit asserts, missing lock

Reviewed-by: mdoerr, amitkumar

! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.cpp

Changeset: 8e0d0190
Branch: premain
Author:    SendaoYan <syan at openjdk.org>
Date:      2024-08-23 06:26:24 +0000
URL:       https://git.openjdk.org/leyden/commit/8e0d0190ed19bc1a9d4ec0c6ee3aa6454542989f

8338630: Test java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout

Reviewed-by: dfuchs, jpai, djelinski

! test/lib/jdk/test/lib/NetworkConfiguration.java

Changeset: 9cbf685b
Branch: premain
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2024-08-23 07:09:40 +0000
URL:       https://git.openjdk.org/leyden/commit/9cbf685b0b1ade5e6ddebfeec225b2efb5cf4cfc

8337658: ZGC: Move soft reference handling out of the driver loop function

Reviewed-by: gli, aboldtch, eosterlund

! src/hotspot/share/gc/z/zDriver.cpp
! src/hotspot/share/gc/z/zDriver.hpp
! src/hotspot/share/gc/z/zGeneration.cpp
! src/hotspot/share/gc/z/zGeneration.hpp
! src/hotspot/share/gc/z/zHeap.inline.hpp
! src/hotspot/share/gc/z/zPageAllocator.cpp
! src/hotspot/share/gc/z/zReferenceProcessor.cpp
! src/hotspot/share/gc/z/zReferenceProcessor.hpp

Changeset: a5e28005
Branch: premain
Author:    Pavel Rappo <prappo at openjdk.org>
Date:      2024-08-23 08:05:16 +0000
URL:       https://git.openjdk.org/leyden/commit/a5e28005fa95426f811e1ed98a7d726cbdbe196d

8338834: Remove unused import declarations in java.compiler

Reviewed-by: darcy

! src/java.compiler/share/classes/javax/annotation/processing/Filer.java
! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
! src/java.compiler/share/classes/javax/lang/model/element/Element.java
! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java
! src/java.compiler/share/classes/javax/lang/model/element/VariableElement.java
! src/java.compiler/share/classes/javax/lang/model/type/TypeVariable.java
! src/java.compiler/share/classes/javax/lang/model/type/TypeVisitor.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitorPreview.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor9.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitorPreview.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor6.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor9.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner6.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner7.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner9.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementScannerPreview.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitorPreview.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor6.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor7.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor6.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor9.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitorPreview.java
! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitorPreview.java
! src/java.compiler/share/classes/javax/lang/model/util/Types.java

Changeset: fead3cf5
Branch: premain
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2024-08-23 09:26:00 +0000
URL:       https://git.openjdk.org/leyden/commit/fead3cf54130e3ab10f94a94dfbd382e4cb1e597

8338745: Intrinsify Continuation.pin() and Continuation.unpin()

Reviewed-by: kvn

! src/hotspot/share/classfile/vmIntrinsics.cpp
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/library_call.hpp
! src/hotspot/share/runtime/continuationEntry.hpp
! src/java.base/share/classes/jdk/internal/vm/Continuation.java

Changeset: 69bd227e
Branch: premain
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2024-08-23 09:29:23 +0000
URL:       https://git.openjdk.org/leyden/commit/69bd227e6c497eb82c46ab85125610c0b44dc04e

8338417: Explicitly pin a virtual thread before acquiring the JFR string pool monitor

Reviewed-by: alanb, egahlin, dholmes

! src/hotspot/share/jfr/writers/jfrJavaEventWriter.cpp
! src/hotspot/share/opto/library_call.cpp
! src/java.base/share/classes/module-info.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/StringPool.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/event/EventWriter.java
+ test/jdk/jdk/jfr/threading/TestStringPoolVirtualThreadPinning.java

Changeset: 965dd1ac
Branch: premain
Author:    Qizheng Xing <qxing at openjdk.org>
Date:      2024-08-23 09:30:47 +0000
URL:       https://git.openjdk.org/leyden/commit/965dd1acd0ce5b225d85e2c55cc097856e0e9f3c

8333334: C2: Make result of `Node::dominates` more precise to enhance scalar replacement

Reviewed-by: chagedorn, kvn, thartmann

! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/memnode.hpp
! src/hotspot/share/opto/node.cpp
! src/hotspot/share/opto/node.hpp
+ test/hotspot/jtreg/compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java
! test/micro/org/openjdk/bench/java/util/concurrent/Maps.java

Changeset: 21d1e4d8
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-08-23 09:59:15 +0000
URL:       https://git.openjdk.org/leyden/commit/21d1e4d8039ecccbf60138ede574e0177ee5550f

8338819: JFR: Internal events causes crash when no other events are in use

Reviewed-by: mgronlun, sjohanss

! src/hotspot/share/jfr/jni/jfrUpcalls.cpp

Changeset: 916f1aa0
Branch: premain
Author:    Tejesh R <tr at openjdk.org>
Date:      2024-08-23 10:51:12 +0000
URL:       https://git.openjdk.org/leyden/commit/916f1aa04f6fcc6da9bf9d725e3639cf4c0755a1

8329756: [macos] "javax/swing/JTable/KeyBoardNavigation.java" fail because most combinations of navigational keys with the Ctrl key do not work

Reviewed-by: abhiscxk, dnguyen

! src/java.desktop/macosx/classes/com/apple/laf/AquaKeyBindings.java
! test/jdk/javax/swing/JTable/KeyBoardNavigation.java

Changeset: a461369f
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-08-23 15:16:44 +0000
URL:       https://git.openjdk.org/leyden/commit/a461369f16a2d92ab428d14c36dd69fa5942bbc5

8338700: AttributeMapper type parameter should be bounded by Attribute

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/AttributeMapper.java
! src/java.base/share/classes/java/lang/classfile/package-info.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java
! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java

Changeset: 23dc3b02
Branch: premain
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-08-23 16:32:14 +0000
URL:       https://git.openjdk.org/leyden/commit/23dc3b02468836f4c9b4303f2c7c0a7305461ce1

8324048: (fc) Make FileKey fields final

Reviewed-by: djelinski, alanb, jpai

! src/java.base/unix/classes/sun/nio/ch/FileKey.java
! src/java.base/unix/native/libnio/ch/FileKey.c
! src/java.base/windows/classes/sun/nio/ch/FileKey.java
! src/java.base/windows/native/libnio/ch/FileKey.c

Changeset: 5d12ac3f
Branch: premain
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-08-23 20:01:16 +0000
URL:       https://git.openjdk.org/leyden/commit/5d12ac3fcb076bf701d7a572942f57f4de7a9ca0

8337715: Update --release 23 symbol information for JDK 23 build 37

Reviewed-by: iris, liach

! src/jdk.compiler/share/data/symbols/java.base-N.sym.txt

Changeset: 32b3d707
Branch: premain
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2024-08-23 22:04:43 +0000
URL:       https://git.openjdk.org/leyden/commit/32b3d707c1b3a9a0d127684e245e5c975ac5566a

8338925: ProblemList runtime/interpreter/LastJsrTest.java on linux-all

Reviewed-by: matsaave

! test/hotspot/jtreg/ProblemList.txt

Changeset: 5671f836
Branch: premain
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2024-08-24 00:05:30 +0000
URL:       https://git.openjdk.org/leyden/commit/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d

8338785: The java.awt.datatransfer.SystemFlavorMap#FLAVOR_MAP_KEY field is not used

Reviewed-by: honkar, dnguyen, prr

! src/java.datatransfer/share/classes/java/awt/datatransfer/SystemFlavorMap.java

Changeset: 0c14579f
Branch: premain
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2024-08-26 07:31:04 +0000
URL:       https://git.openjdk.org/leyden/commit/0c14579fef902f0501d0510bdc32e8cece34834a

8336830: C2: assert(get_loop(lca)->_nest < n_loop->_nest || lca->in(0)->is_NeverBranch()) failed: must not be moved into inner loop

Co-authored-by: Emanuel Peter <epeter at openjdk.org>
Reviewed-by: thartmann, chagedorn, epeter

! src/hotspot/share/opto/loopopts.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestSunkNodeInInfiniteLoop.java

Changeset: ce83f6af
Branch: premain
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2024-08-26 07:32:19 +0000
URL:       https://git.openjdk.org/leyden/commit/ce83f6af64efd673b83c945765f68e8a3bf89774

8338844: C2: remove useless code in PhaseIdealLoop::place_outside_loop() after 8335709

Reviewed-by: chagedorn, thartmann

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

Changeset: 20d8f58c
Branch: premain
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-08-26 09:17:45 +0000
URL:       https://git.openjdk.org/leyden/commit/20d8f58c92009a46dfb91b951e7d87b4cb8e8b41

8331671: Implement JEP 472: Prepare to Restrict the Use of JNI

Reviewed-by: jpai, prr, ihse, kcr, alanb

! make/conf/module-loader-map.conf
! make/test/BuildTestLib.gmk
! src/hotspot/share/classfile/vmClassMacros.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/prims/nativeLookup.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/lang/Module.java
! src/java.base/share/classes/java/lang/ModuleLayer.java
! src/java.base/share/classes/java/lang/Runtime.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/foreign/AddressLayout.java
! src/java.base/share/classes/java/lang/foreign/Linker.java
! src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
! src/java.base/share/classes/java/lang/foreign/package-info.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
! src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
! src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java
! src/java.base/share/classes/jdk/internal/foreign/layout/ValueLayouts.java
! src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java
! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
! src/java.base/share/classes/jdk/internal/reflect/Reflection.java
! src/java.base/share/classes/sun/launcher/resources/launcher.properties
! src/java.base/share/man/java.1
! src/java.desktop/macosx/classes/com/apple/eio/FileManager.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaFileView.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuBarUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaNativeResources.java
! src/java.desktop/macosx/classes/com/apple/laf/ScreenMenu.java
! src/java.desktop/macosx/classes/sun/awt/PlatformGraphicsInfo.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java
! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java
! src/java.desktop/share/classes/com/sun/media/sound/Platform.java
! src/java.desktop/share/classes/java/awt/SplashScreen.java
! src/java.desktop/share/classes/java/awt/Toolkit.java
! src/java.desktop/share/classes/java/awt/event/NativeLibLoader.java
! src/java.desktop/share/classes/java/awt/image/ColorModel.java
! src/java.desktop/share/classes/sun/awt/NativeLibLoader.java
! src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
! src/java.desktop/share/classes/sun/awt/image/JPEGImageDecoder.java
! src/java.desktop/share/classes/sun/awt/image/NativeLibLoader.java
! src/java.desktop/share/classes/sun/font/FontManagerNativeLibrary.java
! src/java.desktop/share/classes/sun/java2d/Disposer.java
! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMS.java
! src/java.desktop/unix/classes/sun/awt/X11GraphicsEnvironment.java
! src/java.desktop/unix/classes/sun/print/CUPSPrinter.java
! src/java.desktop/windows/classes/sun/awt/PlatformGraphicsInfo.java
! src/java.desktop/windows/classes/sun/awt/windows/WToolkit.java
! src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java
! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java
! src/java.management/share/classes/java/lang/management/ManagementFactory.java
! src/java.prefs/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java
! src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java
! src/java.prefs/windows/classes/java/util/prefs/WindowsPreferences.java
! src/java.rmi/share/classes/sun/rmi/transport/GC.java
! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java
! src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java
! src/java.security.jgss/share/classes/sun/security/krb5/SCDynamicStoreConfig.java
! src/java.smartcardio/unix/classes/sun/security/smartcardio/PlatformPCSC.java
! src/java.smartcardio/windows/classes/sun/security/smartcardio/PlatformPCSC.java
! src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java
! src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java
! src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
! src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
! src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java
! src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java
! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java
! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/SunMSCAPI.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java
! src/jdk.jdi/windows/classes/com/sun/tools/jdi/SharedMemoryTransportService.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/ExecutableRebrander.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinExeBundler.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WindowsRegistry.java
! src/jdk.management.agent/unix/classes/jdk/internal/agent/FileSystemImpl.java
! src/jdk.management.agent/windows/classes/jdk/internal/agent/FileSystemImpl.java
! src/jdk.management/share/classes/com/sun/management/internal/Flag.java
! src/jdk.management/share/classes/com/sun/management/internal/PlatformMBeanProviderImpl.java
! src/jdk.net/aix/classes/jdk/net/AIXSocketOptions.java
! src/jdk.net/linux/classes/jdk/net/LinuxSocketOptions.java
! src/jdk.net/macosx/classes/jdk/net/MacOSXSocketOptions.java
! src/jdk.net/windows/classes/jdk/net/WindowsSocketOptions.java
! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpChannelImpl.java
! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpNet.java
! src/jdk.security.auth/share/classes/com/sun/security/auth/module/NTSystem.java
! src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
! test/hotspot/jtreg/runtime/jni/checked/TestCheckedReleaseArrayElements.java
! test/jdk/java/foreign/TestRestricted.java
! test/jdk/java/foreign/enablenativeaccess/TestEnableNativeAccess.java
! test/jdk/java/foreign/enablenativeaccess/TestEnableNativeAccessBase.java
! test/jdk/java/foreign/enablenativeaccess/TestEnableNativeAccessDynamic.java
= test/jdk/java/foreign/enablenativeaccess/panama_jni_def_module/module-info.java
+ test/jdk/java/foreign/enablenativeaccess/panama_jni_def_module/org/openjdk/jni/def/PanamaJNIDef.java
= test/jdk/java/foreign/enablenativeaccess/panama_jni_def_module/org/openjdk/jni/def/libLinkerInvokerModule.cpp
= test/jdk/java/foreign/enablenativeaccess/panama_jni_load_module/module-info.java
+ test/jdk/java/foreign/enablenativeaccess/panama_jni_load_module/org/openjdk/jni/PanamaMainJNI.java
= test/jdk/java/foreign/enablenativeaccess/panama_jni_use_module/module-info.java
+ test/jdk/java/foreign/enablenativeaccess/panama_jni_use_module/org/openjdk/jni/use/PanamaJNIUse.java
- test/jdk/java/foreign/enablenativeaccess/panama_module/org/openjdk/foreigntest/PanamaMainJNI.java
! test/jdk/java/foreign/handles/Driver.java
! test/jdk/java/foreign/handles/invoker_module/handle/invoker/MethodHandleInvoker.java
! test/jdk/java/foreign/handles/lookup_module/handle/lookup/MethodHandleLookup.java

Changeset: e63418ee
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-08-26 14:29:09 +0000
URL:       https://git.openjdk.org/leyden/commit/e63418ee017def80689c88671e5d124b2d453fda

8338979: Avoid bootstrapped switches in the classfile API

Reviewed-by: liach, asotona

! src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java

Changeset: 3f00da84
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-08-26 15:58:25 +0000
URL:       https://git.openjdk.org/leyden/commit/3f00da84b3e6fb001e7d56acb198292b28d40c8b

8338906: Avoid passing EnumDescs and extra classes to type switch methods that don't use them

Reviewed-by: liach, jlahoda

! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java

Changeset: a15af699
Branch: premain
Author:    Tom?? Zezula <tomas.zezula at gmail.com>
Committer: Doug Simon <dnsimon at openjdk.org>
Date:      2024-08-26 16:49:48 +0000
URL:       https://git.openjdk.org/leyden/commit/a15af6998e8f7adac2ded94ef5a47e22ddb53452

8338538: [JVMCI] Allow HotSpotJVMCIRuntime#getJObjectValue to be called by a HotSpot CompileBroker compiler thread

Reviewed-by: dnsimon

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

Changeset: 0c744ea7
Branch: premain
Author:    Phil Race <prr at openjdk.org>
Date:      2024-08-26 18:52:36 +0000
URL:       https://git.openjdk.org/leyden/commit/0c744ea7e75ba117503afe9c03993f3532742bb3

8338928: Update SwingSet2 "About" image to reference openjdk.org

Reviewed-by: abhiscxk, honkar

! src/demo/share/jfc/SwingSet2/resources/images/About.jpg

Changeset: 5ecbecfb
Branch: premain
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-08-26 20:26:17 +0000
URL:       https://git.openjdk.org/leyden/commit/5ecbecfbcac681e9e6750be37ca4bc2591db21e6

8338936: StringConcatFactory optimize the construction of MethodType and MethodTypeDesc

Reviewed-by: redestad, liach

! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java

Changeset: a827ff05
Branch: premain
Author:    Calvin Cheung <ccheung at openjdk.org>
Date:      2024-08-26 21:26:12 +0000
URL:       https://git.openjdk.org/leyden/commit/a827ff05dba0c9b7c74d83053a35c8041c1ac5cc

8335577: runtime/cds/appcds/TestParallelGCWithCDS.java still fails with JNI error

Reviewed-by: dholmes, iklam

! test/hotspot/jtreg/runtime/cds/appcds/TestParallelGCWithCDS.java

Changeset: 16df0907
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-08-26 22:26:40 +0000
URL:       https://git.openjdk.org/leyden/commit/16df0907842af4729e72fe706c76681c8c799c03

8338947: Deprecate the UseLinuxPosixThreadCPUClocks flag and remove it in a future release

Reviewed-by: kbarrett, stuefe

! src/hotspot/os/linux/globals_linux.hpp
! src/hotspot/share/runtime/arguments.cpp
! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java

Changeset: 78f53efc
Branch: premain
Author:    Chihiro Ito <cito at openjdk.org>
Date:      2024-08-27 00:24:46 +0000
URL:       https://git.openjdk.org/leyden/commit/78f53efcd6a886375fac3fad69f428ecc852fcd6

8338938: The result of the combine method of SettingsControl is not used

Reviewed-by: egahlin

! src/jdk.jfr/share/classes/jdk/jfr/internal/Control.java
! test/jdk/jdk/jfr/api/settings/TestFilterEvents.java

Changeset: cd9e241f
Branch: premain
Author:    Julian Waters <jwaters at openjdk.org>
Date:      2024-08-27 04:13:54 +0000
URL:       https://git.openjdk.org/leyden/commit/cd9e241f0ec10c7b31d36cbfb994bc20d81a0517

8336289: Obliterate most references to _snprintf in the Windows JDK

Reviewed-by: kbarrett, dholmes, jpai, mullan, djelinski, prr

! src/hotspot/os/windows/attachListener_windows.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/os/windows/perfMemory_windows.cpp
! src/java.base/windows/native/libjli/cmdtoargs.c
! src/java.desktop/share/native/libsplashscreen/splashscreen_impl.c
! src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp
! src/jdk.accessibility/windows/native/jaccessinspector/jaccessinspector.cpp
! src/jdk.crypto.cryptoki/windows/native/libj2pkcs11/j2secmod_md.c
! src/jdk.hotspot.agent/share/native/libsaproc/sadis.c
! src/jdk.jdwp.agent/windows/native/libjdwp/linker_md.c
! src/jdk.jdwp.agent/windows/native/libjdwp/util_md.h
! src/jdk.management/windows/native/libmanagement_ext/OperatingSystemImpl.c

Changeset: b8e8e965
Branch: premain
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Date:      2024-08-27 04:15:08 +0000
URL:       https://git.openjdk.org/leyden/commit/b8e8e965e541881605f9dbcd4d9871d4952b9232

8338668: Test javax/swing/JFileChooser/8080628/bug8080628.java doesn't test for GTK L&F

Reviewed-by: aivanov, honkar, prr

! test/jdk/javax/swing/JFileChooser/8080628/bug8080628.java

Changeset: b704bfa2
Branch: premain
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-08-27 07:23:15 +0000
URL:       https://git.openjdk.org/leyden/commit/b704bfa205bbd8c56f128ce5d727d40c8a3ec613

8298920: Improve microbenchmark build times

Reviewed-by: erikj, ihse, djelinski

! make/common/JavaCompilation.gmk
! make/test/BuildMicrobenchmark.gmk

Changeset: aefdbdc7
Branch: premain
Author:    Robbin Ehn <rehn at openjdk.org>
Date:      2024-08-27 08:42:06 +0000
URL:       https://git.openjdk.org/leyden/commit/aefdbdc7e54ae92b5c2113504ce17abf00681e62

8338727: RISC-V: Avoid synthetic data dependency in nmethod barrier on Ztso

Reviewed-by: mli, fyang

! src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp

Changeset: 2edf574f
Branch: premain
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2024-08-27 11:51:28 +0000
URL:       https://git.openjdk.org/leyden/commit/2edf574f62837678e621e1dfdd8d8a77dbe17ad6

8338814: [PPC64] Unify interface of cmpxchg for different types

Reviewed-by: lucy

! src/hotspot/cpu/ppc/assembler_ppc.cpp
! src/hotspot/cpu/ppc/assembler_ppc.hpp
! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp
! src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
! src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/ppc/vtableStubs_ppc_64.cpp

Changeset: d5c6158c
Branch: premain
Author:    Joakim Nordstr?m <jnordstrom at openjdk.org>
Committer: Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2024-08-27 13:17:21 +0000
URL:       https://git.openjdk.org/leyden/commit/d5c6158cedfd96a9f97d83355b10730b81274648

8338389: [JFR] Long strings should be added to the string pool

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/StringPool.java
+ test/jdk/jdk/jfr/jvm/TestLongStringsInPool.java

Changeset: 414d23cb
Branch: premain
Author:    Viktor Klang <vklang at openjdk.org>
Date:      2024-08-27 13:23:02 +0000
URL:       https://git.openjdk.org/leyden/commit/414d23cb8f3c2765ac6ba2da930f2cfe7a9ad419

8338765: ScheduledThreadPoolExecutor struggles with extremely long delays

Reviewed-by: alanb

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

Changeset: b25095b0
Branch: premain
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-08-27 14:26:31 +0000
URL:       https://git.openjdk.org/leyden/commit/b25095b08e4d21b95177a5fa3fff3807b2cf81e0

8338728: Misc issues in memory layout javadoc

Reviewed-by: pminborg, psandoz

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

Changeset: 0f667103
Branch: premain
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2024-08-27 14:33:31 +0000
URL:       https://git.openjdk.org/leyden/commit/0f667103db7842fe9d3399f56baee0a5def4529e

8338939: Simplify processing of hidden class names

Reviewed-by: egahlin

! src/hotspot/share/jfr/support/jfrSymbolTable.cpp
! src/hotspot/share/jfr/support/jfrSymbolTable.hpp

Changeset: 1ff5f8d6
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-08-27 15:18:34 +0000
URL:       https://git.openjdk.org/leyden/commit/1ff5f8d65cf6153e517ee7a242d10536eee0d637

8338440: Parallel: Improve fragmentation mitigation in Full GC

Co-authored-by: Guoxiong Li <gli at openjdk.org>
Reviewed-by: iwalulya, zgu, gli

! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.hpp

Changeset: fa4ff78b
Branch: premain
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-08-27 15:34:50 +0000
URL:       https://git.openjdk.org/leyden/commit/fa4ff78bd4ed029120717142eec6fb6352cb8e79

8338690: CompactNumberInstance.format incorrectly formats some numbers (few vs many)

Reviewed-by: joehw, rriggs, jlu

! src/java.base/share/classes/java/text/CompactNumberFormat.java
! src/java.base/share/classes/java/text/DecimalFormat.java
! test/jdk/java/text/Format/CompactNumberFormat/TestCompactNumber.java

Changeset: daf26178
Branch: premain
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-08-27 15:46:10 +0000
URL:       https://git.openjdk.org/leyden/commit/daf26178be07bfe4a46592bcde092ce297a092bb

8338929: Make Metaspace::deallocate space-aware

Reviewed-by: coleenp, adinn

! src/hotspot/share/memory/classLoaderMetaspace.cpp
! src/hotspot/share/memory/classLoaderMetaspace.hpp
! src/hotspot/share/memory/metadataFactory.hpp
! src/hotspot/share/memory/metaspace.cpp
! src/hotspot/share/memory/metaspace.hpp
! test/hotspot/gtest/metaspace/test_metaspace_misc.cpp

Changeset: 44d3a68d
Branch: premain
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-08-27 16:20:18 +0000
URL:       https://git.openjdk.org/leyden/commit/44d3a68d8a73c119b64772687d74e5ce25926f4f

8314124: RISC-V: implement Base64 intrinsic - decoding

Reviewed-by: fyang, rehn, tonyp

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

Changeset: 2e96f159
Branch: premain
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-08-27 16:24:50 +0000
URL:       https://git.openjdk.org/leyden/commit/2e96f159aaee782a627902c04dbd51daa3406ab5

8338489: Typo in MemorySegment doc

Reviewed-by: rriggs, mcimadamore, iris

! src/java.base/share/classes/java/lang/foreign/MemorySegment.java

Changeset: 284c3cde
Branch: premain
Author:    Neethu Prasad <nprasad at openjdk.org>
Date:      2024-08-27 16:45:34 +0000
URL:       https://git.openjdk.org/leyden/commit/284c3cde5e1b7115fb17c51f3ed17c1be95845bc

8336299: Improve GCLocker stall diagnostics

Reviewed-by: ayang, shade, tschatzl

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

Changeset: b1b4cd42
Branch: premain
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
Date:      2024-08-27 17:16:09 +0000
URL:       https://git.openjdk.org/leyden/commit/b1b4cd429a4135840966975dd0c068fe428e2ee6

8332158: [XWayland] test/jdk/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java

Reviewed-by: serb, honkar

! test/jdk/ProblemList.txt
! test/jdk/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java

Changeset: 449ca2c3
Branch: premain
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-08-27 22:10:05 +0000
URL:       https://git.openjdk.org/leyden/commit/449ca2c3c1cb5d056a2d259be2ff069ba2a36b80

8337832: Optimize datetime toString

Reviewed-by: scolebourne, liach, naoto

! src/java.base/share/classes/java/time/LocalDateTime.java
! src/java.base/share/classes/java/time/OffsetDateTime.java
! src/java.base/share/classes/java/time/OffsetTime.java
! src/java.base/share/classes/java/time/ZonedDateTime.java

Changeset: 8e88da05
Branch: premain
Author:    Tejesh R <tr at openjdk.org>
Date:      2024-08-28 04:43:10 +0000
URL:       https://git.openjdk.org/leyden/commit/8e88da05b9966892e117b779d59a2e311a557a8d

8338041: Keyboard Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F

Reviewed-by: honkar, prr, abhiscxk

! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java
+ test/jdk/javax/swing/plaf/gtk/JTableCtrlShiftRightLeftKeyTest.java

Changeset: 2e174c63
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-08-28 09:29:18 +0000
URL:       https://git.openjdk.org/leyden/commit/2e174c6367c7755d8541f9669f7f10ed89878f58

8338445: jdk.internal.loader.URLClassPath may leak JarFile instance when dealing with unexpected Class-Path entry in manifest

Reviewed-by: michaelm, cstein, alanb

! src/java.base/share/classes/jdk/internal/loader/URLClassPath.java
+ test/jdk/java/net/URLClassLoader/JarLoaderCloseTest.java

Changeset: 1ff9ac72
Branch: premain
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-08-28 10:22:34 +0000
URL:       https://git.openjdk.org/leyden/commit/1ff9ac7233d51a58fd54a92d2c45761478574cc7

8338731: MemoryLayout::offsetHandle can return a negative offset

Reviewed-by: pminborg, psandoz

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

Changeset: 21505216
Branch: premain
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Pavel Rappo <prappo at openjdk.org>
Date:      2024-08-28 11:01:15 +0000
URL:       https://git.openjdk.org/leyden/commit/2150521650d6b730cfe9d3ecb91d589c96862475

8322036: Improve help output from the javadoc tool

Reviewed-by: prappo

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOptions.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties

Changeset: 9d183bd0
Branch: premain
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2024-08-28 12:19:58 +0000
URL:       https://git.openjdk.org/leyden/commit/9d183bd02763ee4ff5aa8388e039d8b5a6964328

8339149: jfr_flush_event_writer - return value type mismatch

Reviewed-by: egahlin

! src/hotspot/share/jfr/jni/jfrJniMethod.hpp

Changeset: 32c97509
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-08-28 13:28:01 +0000
URL:       https://git.openjdk.org/leyden/commit/32c975098521e830ce706b67e7232a007c0846c7

8339160: [BACKOUT] JDK-8338440 Parallel: Improve fragmentation mitigation in Full GC

Reviewed-by: tschatzl

! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.hpp

Changeset: b6700095
Branch: premain
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Date:      2024-08-28 15:23:50 +0000
URL:       https://git.openjdk.org/leyden/commit/b6700095c018a67a55b746cd4eee763c68f538e0

8338729: Retire the test jdk/java/util/zip/TestZipError.java

Reviewed-by: lancea

- test/jdk/java/util/zip/TestZipError.java

Changeset: 379f3db0
Branch: premain
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2024-08-28 16:47:30 +0000
URL:       https://git.openjdk.org/leyden/commit/379f3db001fe4bffd3a00e0363a98275e7b2eba8

8339175: ProblemList runtime/interpreter/LastJsrTest.java on all platforms with Xcomp

Reviewed-by: matsaave

! test/hotspot/jtreg/ProblemList-Xcomp.txt
! test/hotspot/jtreg/ProblemList.txt

Changeset: 0c2b1758
Branch: premain
Author:    Anthony Scarpino <ascarpino at openjdk.org>
Date:      2024-08-28 17:24:33 +0000
URL:       https://git.openjdk.org/leyden/commit/0c2b175898d13b58ffe56e2f9cbc9d88173a61cf

8328608: Multiple NewSessionTicket support for TLS

Reviewed-by: djelinski

! src/java.base/share/classes/sun/security/ssl/Finished.java
! src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java
! src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java
! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java
! src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java
! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java
! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/java.base/share/classes/sun/security/util/Cache.java
! test/jdk/javax/net/ssl/SSLSession/CertMsgCheck.java
! test/jdk/javax/net/ssl/SSLSession/CheckSessionContext.java
! test/jdk/javax/net/ssl/templates/TLSBase.java
+ test/jdk/sun/security/ssl/SSLSessionImpl/MultiNSTClient.java
+ test/jdk/sun/security/ssl/SSLSessionImpl/MultiNSTNoSessionCreation.java
+ test/jdk/sun/security/ssl/SSLSessionImpl/MultiNSTParallel.java
+ test/jdk/sun/security/ssl/SSLSessionImpl/MultiNSTSequence.java

Changeset: 3d49fb8a
Branch: premain
Author:    Manukumar V S <mvs at openjdk.org>
Date:      2024-08-28 17:54:43 +0000
URL:       https://git.openjdk.org/leyden/commit/3d49fb8a17ceec6e23595bc8affc89765899f72b

8338103: Stabilize and open source a Swing OGL ButtonResizeTest

Reviewed-by: abhiscxk, prr, tr

+ test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java

Changeset: a98ecad0
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-08-28 18:16:00 +0000
URL:       https://git.openjdk.org/leyden/commit/a98ecad0a920f12d81386de3d0f549d542014773

8338897: Small startup regression remains after JDK-8309622 and JDK-8331932

Reviewed-by: liach, naoto

! src/java.base/share/classes/java/util/Locale.java
! src/java.base/share/classes/sun/util/locale/BaseLocale.java

Changeset: eff6d9cd
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-08-28 18:22:30 +0000
URL:       https://git.openjdk.org/leyden/commit/eff6d9cd23f9da8720a44ad628aa0a3e6f58facf

8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce boxing overheads

Reviewed-by: liach

! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
! src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java

Changeset: d03ec7aa
Branch: premain
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-08-28 20:17:25 +0000
URL:       https://git.openjdk.org/leyden/commit/d03ec7aad41d830b47801b7af75ee5e278128e69

8339030: frame::print_value_on(outputStream* st, JavaThread *thread) doesn't need thread argument

Reviewed-by: dholmes, coleenp

! src/hotspot/share/oops/instanceStackChunkKlass.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/continuationFreezeThaw.cpp
! src/hotspot/share/runtime/frame.cpp
! src/hotspot/share/runtime/frame.hpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/vframe.cpp

Changeset: d08b5bd9
Branch: premain
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-08-28 20:18:51 +0000
URL:       https://git.openjdk.org/leyden/commit/d08b5bd9f5f740d75c1acfbd644ce1c822e03833

8258483: [TESTBUG] gtest CollectorPolicy.young_scaled_initial_ergo_vm fails if heap is too small

Reviewed-by: ayang

! test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp

Changeset: a8ac2872
Branch: premain
Author:    Justin Lu <jlu at openjdk.org>
Date:      2024-08-28 21:14:29 +0000
URL:       https://git.openjdk.org/leyden/commit/a8ac28725bfc22867c76856ddce094588a97b84c

8339126: JNI exception pending in Inflater.c

Reviewed-by: lancea, vtewari, jpai, naoto

! src/java.base/share/native/libzip/Inflater.c

Changeset: 72a49005
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-08-28 21:16:18 +0000
URL:       https://git.openjdk.org/leyden/commit/72a49005ee8c4aeb6dcf3eff4c56576a2b4d0081

8338888: SystemDictionary::class_name_symbol has incorrect length check

Reviewed-by: stuefe, kbarrett, coleenp

! src/hotspot/share/classfile/systemDictionary.cpp
! test/hotspot/jtreg/runtime/exceptionMsgs/NoClassDefFoundError/NoClassDefFoundErrorTest.java
! test/hotspot/jtreg/runtime/exceptionMsgs/NoClassDefFoundError/libNoClassDefFoundErrorTest.c

Changeset: 26e3d535
Branch: premain
Author:    Brent Christian <bchristi at openjdk.org>
Date:      2024-08-28 22:54:38 +0000
URL:       https://git.openjdk.org/leyden/commit/26e3d535ad4d6e5d78ca50941cfa39dd337892a9

8338716: Re-visit "interrupt handling" in jdk.internal.loader.Resource

Reviewed-by: alanb

! src/java.base/share/classes/jdk/internal/loader/Resource.java

Changeset: 0ddcd701
Branch: premain
Author:    Dean Long <dlong at openjdk.org>
Date:      2024-08-29 00:34:11 +0000
URL:       https://git.openjdk.org/leyden/commit/0ddcd7017576a0f9c97a74b7d47624ae06ed06d6

8335120: assert(!target->can_be_statically_bound() || target == cha_monomorphic_target) failed

Reviewed-by: kvn, vlivanov

! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciMethod.hpp

Changeset: eb7ead58
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-08-29 05:03:15 +0000
URL:       https://git.openjdk.org/leyden/commit/eb7ead58fd70822669d2aa1a0053814e58955f82

8336873: BasicSplitPaneDivider:oneTouchExpandableChanged() should mention that implementation depends on SplitPane.supportsOneTouchButtons property

Reviewed-by: prr, abhiscxk

! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java

Changeset: 1383fec4
Branch: premain
Author:    Kangcheng Xu <kxu at openjdk.org>
Date:      2024-08-29 05:34:08 +0000
URL:       https://git.openjdk.org/leyden/commit/1383fec41756322bf2832c55633e46395b937b40

8327381: Refactor type-improving transformations in BoolNode::Ideal to BoolNode::Value

Reviewed-by: chagedorn, thartmann, jkarthikeyan, epeter

! src/hotspot/share/opto/subnode.cpp
! src/hotspot/share/opto/subnode.hpp
+ test/hotspot/jtreg/compiler/c2/gvn/TestBoolNodeGVN.java
! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java

Changeset: 0b4a7d53
Branch: premain
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-08-29 06:25:27 +0000
URL:       https://git.openjdk.org/leyden/commit/0b4a7d534204b7b3b041f5117282dd13b1c7c62f

8324859: Improve error recovery

Reviewed-by: mcimadamore

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

Changeset: ff59532d
Branch: premain
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-08-29 06:28:05 +0000
URL:       https://git.openjdk.org/leyden/commit/ff59532ddd3002df61e46d58b3f29d26c78295da

8338678: Erroneous parameterized type represented as <any>

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! test/langtools/tools/javac/recovery/AttrRecovery.java

Changeset: f080b4bb
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-08-29 07:07:12 +0000
URL:       https://git.openjdk.org/leyden/commit/f080b4bb8a75284db1b6037f8c00ef3b1ef1add1

8333098: ubsan: bytecodeInfo.cpp:318:59: runtime error: division by zero

Reviewed-by: kvn, iveresov

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

Changeset: 362f9ce0
Branch: premain
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-08-29 07:29:12 +0000
URL:       https://git.openjdk.org/leyden/commit/362f9ce077baa900ed81a0473ec0187efde132ef

8339120: Use more fine-granular gcc unused warnings

Reviewed-by: jwaters, kbarrett, erikj

! make/autoconf/flags-cflags.m4
! make/common/TestFilesCompilation.gmk
! make/common/modules/LauncherCommon.gmk
! make/hotspot/lib/CompileGtest.gmk
! make/hotspot/lib/CompileJvm.gmk
! make/modules/java.base/Lib.gmk
! make/modules/java.base/lib/CoreLibraries.gmk
! make/modules/java.desktop/Lib.gmk
! make/modules/java.desktop/lib/AwtLibraries.gmk
! make/modules/java.desktop/lib/ClientLibraries.gmk
! make/modules/java.management/Lib.gmk
! make/modules/java.security.jgss/Lib.gmk
! make/modules/jdk.crypto.cryptoki/Lib.gmk
! make/modules/jdk.hotspot.agent/Lib.gmk
! make/modules/jdk.jdwp.agent/Lib.gmk
! make/modules/jdk.jpackage/Lib.gmk
! make/modules/jdk.management/Lib.gmk

Changeset: 723588a4
Branch: premain
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-08-29 08:54:02 +0000
URL:       https://git.openjdk.org/leyden/commit/723588a4e78d25f0ef3c4cdaeb377aedc3a352d4

8338569: HTTP/1.1 CleanupTrigger may be triggerred after the next exchange started

Reviewed-by: jpai

! src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
! src/java.net.http/share/classes/jdk/internal/net/http/SocketTube.java
! src/java.net.http/share/classes/jdk/internal/net/http/common/FlowTube.java
! test/jdk/java/net/httpclient/DigestEchoClient.java
! test/jdk/java/net/httpclient/ShutdownNow.java
! test/jdk/java/net/httpclient/SmokeTest.java

Changeset: d35ffa4f
Branch: premain
Author:    Andrey Turbanov <aturbanov at openjdk.org>
Date:      2024-08-29 09:57:52 +0000
URL:       https://git.openjdk.org/leyden/commit/d35ffa4f6afb7df052103cee8544e4e707b72cc1

8339017: Make a couple of fields in DoubleByte static

Reviewed-by: bpb, naoto

! src/java.base/share/classes/sun/nio/cs/DoubleByte.java

Changeset: 8c8b5801
Branch: premain
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-08-29 10:06:08 +0000
URL:       https://git.openjdk.org/leyden/commit/8c8b5801fd9d28a71edf3bd8d1fae857817e27de

8338281: jshell does not run shutdown hooks

Reviewed-by: asotona

! src/jdk.jshell/share/classes/jdk/jshell/execution/ExecutionControlForwarder.java
! src/jdk.jshell/share/classes/jdk/jshell/execution/JdiDefaultExecutionControl.java
! test/langtools/jdk/jshell/ShutdownTest.java

Changeset: e57b5932
Branch: premain
Author:    Johan Sj?len <jsjolen at openjdk.org>
Date:      2024-08-29 11:23:04 +0000
URL:       https://git.openjdk.org/leyden/commit/e57b59325831247818cb4b07c4fd43e4556effca

8335062: NMT: Make StackIndex non-opaque

Reviewed-by: stuefe, gziemski

! src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp
! src/hotspot/share/nmt/vmatree.hpp
! test/hotspot/gtest/nmt/test_nmt_nativecallstackstorage.cpp

Changeset: 777ed2b5
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-08-29 15:45:52 +0000
URL:       https://git.openjdk.org/leyden/commit/777ed2b5d2ef8371407cc9bf0370a7cef937cfb7

8339132: Make DirectCodeBuilder write through without allocating instruction objects

Reviewed-by: asotona, redestad

! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java

Changeset: a4962ace
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-08-29 20:38:52 +0000
URL:       https://git.openjdk.org/leyden/commit/a4962ace4d3afb36e9d6822a4f02a1515fac40ed

8338257: UTF8 lengths should be size_t not int

Reviewed-by: stuefe, coleenp, dlong

! src/hotspot/share/classfile/compactHashtable.cpp
! src/hotspot/share/classfile/compactHashtable.hpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/classfile/modules.cpp
! src/hotspot/share/classfile/stringTable.cpp
! src/hotspot/share/classfile/symbolTable.cpp
! src/hotspot/share/jfr/dcmd/jfrDcmds.cpp
! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.cpp
! src/hotspot/share/oops/symbol.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvmtiEnv.cpp
! src/hotspot/share/services/finalizerService.cpp
! src/hotspot/share/utilities/utf8.cpp
! src/hotspot/share/utilities/utf8.hpp

Changeset: f2968b34
Branch: premain
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-08-29 21:06:05 +0000
URL:       https://git.openjdk.org/leyden/commit/f2968b34a55009fb195e381ffa615488974e9ba6

8339020: Remove unused HeapShared::calculate_oopmap

Reviewed-by: coleenp

! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/heapShared.hpp

Changeset: b711c41d
Branch: premain
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-08-29 21:21:16 +0000
URL:       https://git.openjdk.org/leyden/commit/b711c41d442fc369a84745c0203db638e0b7e671

8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long

Reviewed-by: liach, redestad

! src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java

Changeset: 4675913e
Branch: premain
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2024-08-30 01:06:00 +0000
URL:       https://git.openjdk.org/leyden/commit/4675913edb16ec1dde5f0ba2dfcfada134ce17f1

8339237: RISC-V: Builds fail after JDK-8339120

Reviewed-by: fyang

! src/hotspot/cpu/riscv/c1_Runtime1_riscv.cpp

Changeset: f927c121
Branch: premain
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Date:      2024-08-30 06:21:49 +0000
URL:       https://git.openjdk.org/leyden/commit/f927c1210ee0675bb1196572177ffb505826d57a

8339154: Cleanups and JUnit conversion of test/jdk/java/util/zip/Available.java

Reviewed-by: lancea

! test/jdk/java/util/zip/Available.java

Changeset: b9e65f98
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-08-30 06:47:49 +0000
URL:       https://git.openjdk.org/leyden/commit/b9e65f982fe6ae69d3912f32465a688d67c1c765

8337662: Improve os::print_hex_dump for printing Instructions sections

Reviewed-by: stuefe, lucy

! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! test/hotspot/gtest/runtime/test_os.cpp

Changeset: b8727181
Branch: premain
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-08-30 08:11:49 +0000
URL:       https://git.openjdk.org/leyden/commit/b8727181f3ceac6f37272a1152f267ed1b6e2297

8338301: Error recovery and reporting should be improved for erroneous implicitly declared classes

Reviewed-by: cstein, vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/langtools/tools/javac/ImplicitClass/ErrorRecovery.java
+ test/langtools/tools/javac/diags/examples/ClassMethodOrFieldExpected.java

Changeset: bb28b0d2
Branch: premain
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-08-30 08:58:07 +0000
URL:       https://git.openjdk.org/leyden/commit/bb28b0d2292c0f45decfaac0fb2f4c4284e9c666

8338404: Cross-compilation to different endianness fails after JDK-8318913

Reviewed-by: erikj, fbredberg

! make/CreateJmods.gmk
! make/InterimImage.gmk

Changeset: 2abe2ff6
Branch: premain
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-08-30 08:58:18 +0000
URL:       https://git.openjdk.org/leyden/commit/2abe2ff69b205ccaf502bf8b6de3ce9e1260c386

8339235: Fix indentation in build system

Reviewed-by: erikj

! make/CompileInterimLangtools.gmk
! make/CompileJavaModules.gmk
! make/InitSupport.gmk
! make/autoconf/basic_tools.m4
! make/autoconf/boot-jdk.m4
! make/autoconf/flags-ldflags.m4
! make/autoconf/jdk-options.m4
! make/autoconf/jdk-version.m4
! make/autoconf/lib-bundled.m4
! make/autoconf/lib-freetype.m4
! make/autoconf/lib-hsdis.m4
! make/autoconf/libraries.m4
! make/autoconf/platform.m4
! make/autoconf/toolchain_microsoft.m4
! make/common/FindTests.gmk
! make/common/JavaCompilation.gmk
! make/common/JdkNativeCompilation.gmk
! make/common/MakeBase.gmk
! make/common/Modules.gmk
! make/common/Utils.gmk
! make/common/native/DebugSymbols.gmk
! make/hotspot/gensrc/GensrcAdlc.gmk
! make/hotspot/lib/JvmFeatures.gmk
! make/modules/java.desktop/lib/ClientLibraries.gmk
! make/modules/jdk.accessibility/Launcher.gmk

Changeset: 92c4704e
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-08-30 10:18:19 +0000
URL:       https://git.openjdk.org/leyden/commit/92c4704edf75534b825765d156a7f70377ccb3bb

8339166: java/lang/String/concat/HiddenClassUnloading.java fails on AIX and Linux ppc64le after JDK-8336856

Reviewed-by: redestad, mdoerr

! test/jdk/java/lang/String/concat/HiddenClassUnloading.java

Changeset: 3a352b82
Branch: premain
Author:    David Schlosnagle <davids at palantir.com>
Committer: Erik Gahlin <egahlin at openjdk.org>
Date:      2024-08-30 12:36:33 +0000
URL:       https://git.openjdk.org/leyden/commit/3a352b82591eb522c24108de95e42a3d1e5ceb3a

8339191: JFR: Bulk read support for ChunkInputStream

Reviewed-by: egahlin

! src/jdk.jfr/share/classes/jdk/jfr/internal/ChunkInputStream.java
+ test/jdk/jdk/jfr/api/consumer/TestChunkInputStreamBulkRead.java

Changeset: 2fb83055
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-08-30 14:47:29 +0000
URL:       https://git.openjdk.org/leyden/commit/2fb830553f219e59a44c140e2441695a0d79c404

8339319: ProblemList runtime/exceptionMsgs/NoClassDefFoundError/NoClassDefFoundErrorTest.java

Reviewed-by: dfuchs, dcubed

! test/hotspot/jtreg/ProblemList.txt

Changeset: a528c4b3
Branch: premain
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-08-30 16:43:16 +0000
URL:       https://git.openjdk.org/leyden/commit/a528c4b370be1e7730778268cf8c52ffcfd27048

8339156: Use more fine-granular clang unused warnings

Reviewed-by: erikj, kbarrett

! make/autoconf/flags-cflags.m4
! make/common/TestFilesCompilation.gmk
! make/common/modules/LauncherCommon.gmk
! make/hotspot/lib/CompileJvm.gmk
! make/modules/java.base/Lib.gmk
! make/modules/java.base/lib/CoreLibraries.gmk
! make/modules/java.desktop/Lib.gmk
! make/modules/java.desktop/lib/AwtLibraries.gmk
! make/modules/java.desktop/lib/ClientLibraries.gmk
! make/modules/java.management/Lib.gmk
! make/modules/java.security.jgss/Lib.gmk
! make/modules/jdk.crypto.cryptoki/Lib.gmk
! make/modules/jdk.hotspot.agent/Lib.gmk
! make/modules/jdk.jdwp.agent/Lib.gmk
! make/modules/jdk.jpackage/Lib.gmk
! make/modules/jdk.management/Lib.gmk

Changeset: fef1ef7d
Branch: premain
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-08-30 17:17:10 +0000
URL:       https://git.openjdk.org/leyden/commit/fef1ef7dfe1aed7729b182b2fc8d0dda7d546a56

6426678: (spec) File.createTempFile(prefix, suffix, dir) needs clarification for illegal symbols in suffix

Reviewed-by: alanb

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

Changeset: 25e03b52
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-08-30 17:28:28 +0000
URL:       https://git.openjdk.org/leyden/commit/25e03b52094f46f89f2fe8f20e7e5622928add5f

8339115: Rename TypeKind enum constants to follow code style

Reviewed-by: asotona

! make/jdk/src/classes/build/tools/taglet/JSpec.java
! src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
! src/java.base/share/classes/java/lang/classfile/Opcode.java
! src/java.base/share/classes/java/lang/classfile/TypeKind.java
! src/java.base/share/classes/java/lang/classfile/components/snippet-files/PackageSnippets.java
! src/java.base/share/classes/java/lang/classfile/constantpool/DoubleEntry.java
! src/java.base/share/classes/java/lang/classfile/constantpool/FloatEntry.java
! src/java.base/share/classes/java/lang/classfile/constantpool/IntegerEntry.java
! src/java.base/share/classes/java/lang/classfile/constantpool/LoadableConstantEntry.java
! src/java.base/share/classes/java/lang/classfile/constantpool/LongEntry.java
! src/java.base/share/classes/java/lang/classfile/instruction/ArrayLoadInstruction.java
! src/java.base/share/classes/java/lang/classfile/instruction/ArrayStoreInstruction.java
! src/java.base/share/classes/java/lang/classfile/instruction/NewPrimitiveArrayInstruction.java
! src/java.base/share/classes/java/lang/classfile/snippet-files/PackageSnippets.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/LambdaForm.java
! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
! src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/CodeLocalsShifterImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/CodeStackTrackerImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java
! src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/CodeWriter.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
! test/jdk/jdk/classfile/AdvancedTransformationsTest.java
! test/jdk/jdk/classfile/ArrayTest.java
! test/jdk/jdk/classfile/BuilderBlockTest.java
! test/jdk/jdk/classfile/BuilderTryCatchTest.java
! test/jdk/jdk/classfile/StackTrackerTest.java
! test/jdk/jdk/classfile/TempConstantPoolBuilderTest.java
! test/jdk/jdk/classfile/Utf8EntryTest.java
! test/jdk/jdk/classfile/helpers/ClassRecord.java
! test/jdk/jdk/classfile/helpers/RebuildingTransformation.java
! test/micro/org/openjdk/bench/jdk/classfile/Write.java

Changeset: b840b130
Branch: premain
Author:    Justin Lu <jlu at openjdk.org>
Date:      2024-08-30 18:28:53 +0000
URL:       https://git.openjdk.org/leyden/commit/b840b130df7ccb64d4615460c0654a6315e9302f

8338882: Clarify matching order of MessageFormat subformat factory styles

Reviewed-by: naoto

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

Changeset: 4f071ce0
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-08-31 01:13:07 +0000
URL:       https://git.openjdk.org/leyden/commit/4f071ce074b934d5610e213d348cff8326f1499d

8311163: Parallel: Improve large object handling during evacuation

Reviewed-by: tschatzl, ayang

! src/hotspot/share/gc/parallel/psPromotionManager.cpp
! src/hotspot/share/gc/parallel/psPromotionManager.hpp
! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp
! src/hotspot/share/gc/shared/partialArrayState.hpp
! src/hotspot/share/gc/shared/taskqueue.hpp

Changeset: 392bdd57
Branch: premain
Author:    Fei Yang <fyang at openjdk.org>
Date:      2024-08-31 01:44:17 +0000
URL:       https://git.openjdk.org/leyden/commit/392bdd5734e0ad4e616d52bb7bcafcf85dccbf34

8339248: RISC-V: Remove li64 macro assembler routine and related code

Reviewed-by: rehn, fjiang, luhenry

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

Changeset: 92aafb43
Branch: premain
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-09-01 16:13:53 +0000
URL:       https://git.openjdk.org/leyden/commit/92aafb43424321d8f2552aa34a9a3df291abf992

8338934: vmTestbase/nsk/jvmti/*Field*Watch/TestDescription.java tests timeout intermittently

Reviewed-by: sspitsyn, amenkov

! src/hotspot/share/prims/jvmtiEnv.cpp
! src/hotspot/share/prims/jvmtiEventController.cpp
! src/hotspot/share/runtime/mutexLocker.cpp

Changeset: 9d7d85a6
Branch: premain
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2024-09-02 01:23:50 +0000
URL:       https://git.openjdk.org/leyden/commit/9d7d85a6aa20ed95166f5f2f951597bca1fde841

8339298: Remove unused function declaration poll_for_safepoint

Reviewed-by: fyang, chagedorn

! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.hpp
! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.hpp

Changeset: a136a85b
Branch: premain
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-09-02 09:14:36 +0000
URL:       https://git.openjdk.org/leyden/commit/a136a85b6f5bbc92727883693c1ce31c37a82fd5

8338768: Introduce runtime lookup to check for static builds

Co-authored-by: Magnus Ihse Bursie <ihse at openjdk.org>
Co-authored-by: Jiangli Zhou <jiangli at openjdk.org>
Reviewed-by: prr, jiangli, alanb

! make/modules/jdk.jdwp.agent/Lib.gmk
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/share/compiler/disassembler.cpp
! src/hotspot/share/include/jvm.h
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/java.hpp
+ src/hotspot/share/runtime/linkType.cpp
! src/java.base/macosx/native/libjli/java_md_macosx.m
! src/java.base/share/native/libjli/jli_util.h
+ src/java.base/share/native/libjli/link_type.c
! src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c
! src/jdk.jdwp.agent/share/native/libjdwp/transport.c

Changeset: 03ba37e6
Branch: premain
Author:    Aleksei Efimov <aefimov at openjdk.org>
Date:      2024-09-02 09:32:10 +0000
URL:       https://git.openjdk.org/leyden/commit/03ba37e60ce08def6afd172efc1cdbbcc856c633

8339169: Remove NaiveHuffman coder

Reviewed-by: djelinski, dfuchs

- src/java.net.http/share/classes/jdk/internal/net/http/hpack/NaiveHuffman.java

Changeset: b1163bcc
Branch: premain
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-09-02 14:52:04 +0000
URL:       https://git.openjdk.org/leyden/commit/b1163bcc88a5b88b9a56d5584310f1d679690ab2

8256211: assert fired in java/net/httpclient/DependentPromiseActionsTest (infrequent)

Reviewed-by: jpai

! test/jdk/java/net/httpclient/DependentPromiseActionsTest.java

Changeset: 0e6bb514
Branch: premain
Author:    Joshua Zhu <jzhu at openjdk.org>
Committer: Andrew Dinn <adinn at openjdk.org>
Date:      2024-09-02 15:37:58 +0000
URL:       https://git.openjdk.org/leyden/commit/0e6bb514c8ec7c4a7100fe06eaa9e954a74fda30

8339063: [aarch64] Skip verify_sve_vector_length after native calls if SVE supports 128 bits VL only

Reviewed-by: adinn, fgao

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/aarch64_vector.ad
! src/hotspot/cpu/aarch64/aarch64_vector_ad.m4
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/register_aarch64.hpp
! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp
! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp

Changeset: 62dad3a9
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-09-02 17:57:02 +0000
URL:       https://git.openjdk.org/leyden/commit/62dad3a9ea222b0fbf15668d6e7b1c4ed61b2532

8339351: Remove duplicate line in FileMapHeader::print

Reviewed-by: dholmes

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

Changeset: 3a88fd43
Branch: premain
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2024-09-03 06:58:29 +0000
URL:       https://git.openjdk.org/leyden/commit/3a88fd437dfb218df5d3338c8ee7d70416839cf8

8334724: C2: remove PhaseIdealLoop::cast_incr_before_loop()

Reviewed-by: chagedorn, kvn

! src/hotspot/share/opto/loopTransform.cpp
! src/hotspot/share/opto/loopnode.hpp
! src/hotspot/share/opto/loopopts.cpp

Changeset: dc4fd896
Branch: premain
Author:    Fei Yang <fyang at openjdk.org>
Date:      2024-09-03 06:58:44 +0000
URL:       https://git.openjdk.org/leyden/commit/dc4fd896289db1d2f6f7bbf5795fec533448a48c

8339359: RISC-V: Use auipc explicitly in far_jump and far_call macro assembler routines

Reviewed-by: rehn, luhenry

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

Changeset: 288fa60e
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-09-03 07:56:04 +0000
URL:       https://git.openjdk.org/leyden/commit/288fa60ebee445bb2835f096d144b9c6dea98df6

8338891: HotSpotDiagnosticsMXBean missing @since tag

Reviewed-by: alanb

! src/jdk.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java

Changeset: ed422ed1
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-09-03 07:56:14 +0000
URL:       https://git.openjdk.org/leyden/commit/ed422ed1a3d6cdb733bc878c4173b43eb2dfb3da

8338817: Wrong indent in API docs for java.lang.management.ManagementFactory

Reviewed-by: alanb, dfuchs

! src/java.management/share/classes/java/lang/management/ManagementFactory.java

Changeset: 6f3e3fd0
Branch: premain
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2024-09-03 09:27:59 +0000
URL:       https://git.openjdk.org/leyden/commit/6f3e3fd0d4f5e80e3fdbd26be6483c672479802a

8339411: [PPC64] cmpxchgw/h/b doesn't handle external Label

Reviewed-by: lucy, mbaesken

! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp

Changeset: 633fad8e
Branch: premain
Author:    Damon Fenacci <dfenacci at openjdk.org>
Date:      2024-09-03 09:45:43 +0000
URL:       https://git.openjdk.org/leyden/commit/633fad8e53109bef52190494a8b171035229d2ac

8326615: C1/C2 don't handle allocation failure properly during initialization (RuntimeStub::new_runtime_stub fatal crash)

Reviewed-by: thartmann, kvn

! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/compiler/compilationPolicy.cpp
! src/hotspot/share/compiler/compilerDefinitions.cpp
! src/hotspot/share/compiler/compilerDefinitions.hpp
! src/hotspot/share/compiler/compilerDefinitions.inline.hpp
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/compiler/codecache/CheckSegmentedCodeCache.java

Changeset: 7a418fc0
Branch: premain
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-09-03 10:25:27 +0000
URL:       https://git.openjdk.org/leyden/commit/7a418fc07464fe359a0b45b6d797c65c573770cb

8338967: Improve performance for MemorySegment::fill

Reviewed-by: mcimadamore, psandoz

! src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
+ test/jdk/java/foreign/TestFill.java
+ test/micro/org/openjdk/bench/java/lang/foreign/TestFill.java

Changeset: 8ea6adc6
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-09-03 12:02:49 +0000
URL:       https://git.openjdk.org/leyden/commit/8ea6adc623ca2183046d794eba806065deea916e

8339364: AIX build fails: various unused variable and function warnings

Reviewed-by: mdoerr, clanger, jwaters

! make/modules/java.desktop/lib/AwtLibraries.gmk
! src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c
! src/java.base/unix/native/libjava/TimeZone_md.c
! src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c
! src/java.desktop/unix/native/common/awt/CUPSfuncs.c
! src/java.desktop/unix/native/common/awt/X11Color.c
! src/java.desktop/unix/native/common/awt/fontpath.c
! src/java.desktop/unix/native/common/java2d/x11/X11FontScaler_md.c
! src/java.desktop/unix/native/common/java2d/x11/X11Renderer.c
! src/java.desktop/unix/native/common/java2d/x11/X11SurfaceData.c
! src/java.desktop/unix/native/common/java2d/x11/X11TextRenderer_md.c
! src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c
! src/java.desktop/unix/native/libawt_xawt/awt/multiVis.c
! src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c

Changeset: b94c3deb
Branch: premain
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
Date:      2024-09-03 12:05:02 +0000
URL:       https://git.openjdk.org/leyden/commit/b94c3debf5083dbf5bc21ed7794c1656743ab48e

8339401: Optimize ClassFile load and store instructions

Reviewed-by: liach, redestad

! src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java

Changeset: e0c46d58
Branch: premain
Author:    Viktor Klang <vklang at openjdk.org>
Date:      2024-09-03 12:55:23 +0000
URL:       https://git.openjdk.org/leyden/commit/e0c46d589b12aa644e12e4a4c9e84e035f7cf98d

8325397: sun/java2d/Disposer/TestDisposerRace.java fails in linux-aarch64

Reviewed-by: alanb

! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java
! test/jdk/sun/java2d/Disposer/TestDisposerRace.java

Changeset: 4ca2c208
Branch: premain
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-09-03 13:32:50 +0000
URL:       https://git.openjdk.org/leyden/commit/4ca2c208ea2b308093b4a25b04a274f9b1ec6a1d

8338740: java/net/httpclient/HttpsTunnelAuthTest.java fails with java.io.IOException: HTTP/1.1 header parser received no bytes

Reviewed-by: djelinski, jpai

! test/jdk/java/net/httpclient/ProxyServer.java

Changeset: ad40a122
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-03 13:44:48 +0000
URL:       https://git.openjdk.org/leyden/commit/ad40a122d632d65052b71125c0dfd58c54e3a521

8339214: Remove misleading CodeBuilder.loadConstant(Opcode, ConstantDesc)

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
! src/java.base/share/classes/java/lang/classfile/instruction/ConstantInstruction.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassRemapperImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java
! test/jdk/jdk/classfile/AdaptCodeTest.java
! test/jdk/jdk/classfile/LDCTest.java
! test/jdk/jdk/classfile/OpcodesValidationTest.java
! test/jdk/jdk/classfile/helpers/InstructionModelToCodeBuilder.java

Changeset: 66945e50
Branch: premain
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-09-03 15:31:09 +0000
URL:       https://git.openjdk.org/leyden/commit/66945e501049de3a1e1d73303928af87190ae33c

8339336: Fix build system whitespace to adhere to coding conventions

Reviewed-by: erikj

! make/Bundles.gmk
! make/CompileToolsJdk.gmk
! make/CopyInterimTZDB.gmk
! make/Docs.gmk
! make/Global.gmk
! make/Images.gmk
! make/Init.gmk
! make/InitSupport.gmk
! make/JrtfsJar.gmk
! make/Main.gmk
! make/MainSupport.gmk
! make/RunTests.gmk
! make/RunTestsPrebuilt.gmk
! make/RunTestsPrebuiltSpec.gmk
! make/SourceRevision.gmk
! make/StaticLibsImage.gmk
! make/TestImage.gmk
! make/ToolsHotspot.gmk
! make/ToolsJdk.gmk
! make/ZipSecurity.gmk
! make/autoconf/Makefile.template
! make/autoconf/basic.m4
! make/autoconf/basic_tools.m4
! make/autoconf/boot-jdk.m4
! make/autoconf/bootcycle-spec.gmk.template
! make/autoconf/compare.sh.template
! make/autoconf/configure.ac
! make/autoconf/flags-cflags.m4
! make/autoconf/hotspot.m4
! make/autoconf/jdk-options.m4
! make/autoconf/jdk-version.m4
! make/autoconf/jvm-features.m4
! make/autoconf/lib-tests.m4
! make/autoconf/platform.m4
! make/autoconf/spec.gmk.template
! make/autoconf/toolchain.m4
! make/autoconf/util.m4
! make/autoconf/util_paths.m4
! make/common/CopyFiles.gmk
! make/common/Execute.gmk
! make/common/FileUtils.gmk
! make/common/JarArchive.gmk
! make/common/JavaCompilation.gmk
! make/common/JdkNativeCompilation.gmk
! make/common/MakeBase.gmk
! make/common/MakeIO.gmk
! make/common/Modules.gmk
! make/common/NativeCompilation.gmk
! make/common/ProcessMarkdown.gmk
! make/common/TestFilesCompilation.gmk
! make/common/TextFileProcessing.gmk
! make/common/Utils.gmk
! make/common/ZipArchive.gmk
! make/common/native/CompileFile.gmk
! make/devkit/Makefile
! make/devkit/Tools.gmk
! make/hotspot/CopyToExplodedJdk.gmk
! make/hotspot/lib/CompileGtest.gmk
! make/hotspot/lib/CompileJvm.gmk
! make/hotspot/lib/JvmOverrideFiles.gmk
! make/ide/eclipse/CreateWorkspace.gmk
! make/ide/idea/jdk/idea.gmk
! make/ide/visualstudio/hotspot/CreateVSProject.gmk
! make/ide/vscode/hotspot/CreateVSCodeProject.gmk
! make/modules/java.base/Copy.gmk
! make/modules/java.base/Lib.gmk
! make/modules/java.base/gensrc/GensrcBuffer.gmk
! make/modules/java.base/gensrc/GensrcExceptions.gmk
! make/modules/java.base/gensrc/GensrcMisc.gmk
! make/modules/java.base/gensrc/GensrcModuleLoaderMap.gmk
! make/modules/java.base/lib/CoreLibraries.gmk
! make/modules/java.desktop/lib/AwtLibraries.gmk
! make/modules/java.desktop/lib/ClientLibraries.gmk
! make/modules/java.management/Lib.gmk
! make/modules/jdk.javadoc/Gensrc.gmk
! make/modules/jdk.jdeps/Gensrc.gmk
! make/modules/jdk.jlink/Launcher.gmk
! make/modules/jdk.management/Lib.gmk
! make/test/BuildMicrobenchmark.gmk
! make/test/JtregNativeHotspot.gmk
! make/test/JtregNativeJdk.gmk

Changeset: c3adcb84
Branch: premain
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-09-03 15:31:19 +0000
URL:       https://git.openjdk.org/leyden/commit/c3adcb843953b599b3c93d6b51afcc709ceaf45b

8338916: Build warnings about overriding recipe for jvm-ldflags.txt

Reviewed-by: jwaters, erikj

! make/common/NativeCompilation.gmk
! make/common/native/Link.gmk

Changeset: 0d593cd1
Branch: premain
Author:    Amit Kumar <amitkumar at openjdk.org>
Date:      2024-09-03 15:32:42 +0000
URL:       https://git.openjdk.org/leyden/commit/0d593cd1945e93a7d3c33ad270a81403b6fbeb3f

8339419: [s390x] Problemlist compiler/c2/irTests/TestIfMinMax.java

Reviewed-by: thartmann

! test/hotspot/jtreg/ProblemList.txt

Changeset: cfec3ac9
Branch: premain
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2024-09-03 19:01:58 +0000
URL:       https://git.openjdk.org/leyden/commit/cfec3ac911a5a947cdb8c516d0a4b8097f0cc1dd

8337317: serviceability/jvmti tests failed with FATAL ERROR in native method: Failed during the GetClassSignature call

Reviewed-by: lmesnik, sspitsyn, cjplummer

! test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp
! test/hotspot/jtreg/serviceability/jvmti/VMObjectAlloc/libVMObjectAlloc.cpp

Changeset: 130ac13c
Branch: premain
Author:    Doug Simon <dnsimon at openjdk.org>
Date:      2024-09-03 19:04:04 +0000
URL:       https://git.openjdk.org/leyden/commit/130ac13cb9c2dede4ceede4ad6c3c820fdea2fe3

8337265: Test static-libs build in GitHub Actions

Reviewed-by: erikj, ihse

! .github/actions/upload-bundles/action.yml
! .github/workflows/build-linux.yml

Changeset: 5ebdf2d2
Branch: premain
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-09-03 19:06:00 +0000
URL:       https://git.openjdk.org/leyden/commit/5ebdf2d2720b82c4e9783fc6a9aa58344d5e2f2a

8338708: Don't create/destroy debug agent cmdQueueLock for each connection

Reviewed-by: amenkov, lmesnik

! src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c
+ test/jdk/com/sun/jdi/ReattachStressTest.java

Changeset: a7120e2b
Branch: premain
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2024-09-03 19:06:10 +0000
URL:       https://git.openjdk.org/leyden/commit/a7120e2b251e1337df5bd4a2808638d28b7d3bd3

8311993: Test serviceability/sa/UniqueVtableTest.java failed: duplicate vtables detected

Reviewed-by: cjplummer, kevinw, dholmes

! src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp

Changeset: a22e932a
Branch: premain
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-09-03 19:51:12 +0000
URL:       https://git.openjdk.org/leyden/commit/a22e932ab838762a013fc25b8061165be93feeb3

8337163: Improve SA error message when failing to attach to a core file

Reviewed-by: amenkov, kevinw

! src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.cpp
! src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m

Changeset: bbb51616
Branch: premain
Author:    Mark Powers <mpowers at openjdk.org>
Date:      2024-09-03 19:55:58 +0000
URL:       https://git.openjdk.org/leyden/commit/bbb516163d400a9c7e923e423fe2a60091b59322

8337664: Distrust TLS server certificates issued after Oct 2024 and anchored by Entrust Root CAs

Reviewed-by: mullan, rhalade

! src/java.base/share/classes/sun/security/validator/CADistrustPolicy.java
+ src/java.base/share/classes/sun/security/validator/EntrustTLSPolicy.java
! src/java.base/share/conf/security/java.security
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/Distrust.java
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/affirmtrustcommercialca-chain.pem
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/affirmtrustnetworkingca-chain.pem
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/affirmtrustpremiumca-chain.pem
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/affirmtrustpremiumeccca-chain.pem
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/entrust2048ca-chain.pem
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/entrustevca-chain.pem
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/entrustrootcaec1-chain.pem
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/entrustrootcag2-chain.pem
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/entrustrootcag4-chain.pem

Changeset: 90f3f432
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-09-04 03:41:42 +0000
URL:       https://git.openjdk.org/leyden/commit/90f3f4325772773f1dc1814c56d7326d5389e2c7

8328877: [JNI] The JNI Specification needs to address the limitations of integer UTF-8 String lengths

Reviewed-by: cjplummer, alanb

! src/hotspot/os/posix/dtrace/hotspot_jni.d
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jniCheck.cpp
! src/hotspot/share/runtime/threads.cpp
! src/hotspot/share/utilities/dtrace_disabled.hpp
! src/java.base/share/native/include/jni.h
! test/hotspot/jtreg/native_sanity/JniVersion.java
+ test/hotspot/jtreg/runtime/jni/checked/TestLargeUTF8Length.java
+ test/hotspot/jtreg/runtime/jni/checked/libTestLargeUTF8Length.c

Changeset: 5998f4b6
Branch: premain
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Date:      2024-09-04 04:26:55 +0000
URL:       https://git.openjdk.org/leyden/commit/5998f4b6f53769f98188ae8c23ea49cc1f7aa802

8308588: Unnecessary synchronized on GTKStyle#ICONS_MAP can be removed

Reviewed-by: tr, aivanov, aturbanov

! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java

Changeset: 9a1024de
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-04 05:05:20 +0000
URL:       https://git.openjdk.org/leyden/commit/9a1024dec68057c7c581ac0a38fc7f96489a0a76

8190329: [macos] Swing InterOp Platform.exit() crash

Co-authored-by: Kevin Rushforth <kcr at openjdk.org>
Reviewed-by: kcr, azvegint

! src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m
! src/java.desktop/macosx/native/libosxapp/ThreadUtilities.h
! src/java.desktop/macosx/native/libosxapp/ThreadUtilities.m

Changeset: f2c992c5
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-09-04 07:09:59 +0000
URL:       https://git.openjdk.org/leyden/commit/f2c992c5af021ab0ff8429fd261314bc7e01f7df

8339300: CollectorPolicy.young_scaled_initial_ergo_vm gtest fails on ppc64 based platforms

Reviewed-by: mdoerr, lucy

! test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp

Changeset: a6186051
Branch: premain
Author:    Joel Sikstr?m <joel.sikstrom at oracle.com>
Committer: Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-04 08:56:02 +0000
URL:       https://git.openjdk.org/leyden/commit/a61860511f67038962c54e114599948ca103dae8

8339399: ZGC: Remove unnecessary page reset when splitting pages

Reviewed-by: stefank, eosterlund, aboldtch

! src/hotspot/share/gc/z/zPage.cpp
! src/hotspot/share/gc/z/zPage.hpp

Changeset: 7ad61605
Branch: premain
Author:    Joel Sikstr?m <joel.sikstrom at oracle.com>
Committer: Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-04 09:09:15 +0000
URL:       https://git.openjdk.org/leyden/commit/7ad61605f1669f51a97f4f263a7afaa9ab7706be

8339163: ZGC: Race in clearing of remembered sets

Reviewed-by: stefank, eosterlund, aboldtch

! src/hotspot/share/gc/z/zRemembered.cpp
! src/hotspot/share/gc/z/zRemembered.hpp

Changeset: 4e2dde2f
Branch: premain
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-09-04 10:35:04 +0000
URL:       https://git.openjdk.org/leyden/commit/4e2dde2f0d6f96d5f07020d2417189f411c4596a

8339371: jlink.log warning when building after JDK-8338404

Reviewed-by: erikj, alanb

! make/InterimImage.gmk

Changeset: e25a9e7f
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-09-04 12:08:16 +0000
URL:       https://git.openjdk.org/leyden/commit/e25a9e7fd86e4eaf020e54021efaa7059dc654c9

8339486: JFR: Modernize

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/query/Function.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/util/StopWatch.java
! test/jdk/jdk/jfr/api/event/TestGetDuration.java
! test/jdk/jdk/jfr/api/recording/misc/TestGetStream.java
! test/jdk/jdk/jfr/api/recording/options/TestDuration.java
! test/jdk/jdk/jfr/api/recording/state/TestStateDuration.java
! test/jdk/jdk/jfr/api/recording/state/TestStateScheduleStart.java
! test/jdk/jdk/jfr/event/runtime/TestThreadCpuTimeEvent.java

Changeset: bd8569bc
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-04 12:29:40 +0000
URL:       https://git.openjdk.org/leyden/commit/bd8569bc6cc888cbf514e9329e2c24a059d89711

8339131: Remove rarely-used accessor methods from Opcode

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
! src/java.base/share/classes/java/lang/classfile/Opcode.java
! src/java.base/share/classes/java/lang/classfile/instruction/ConstantInstruction.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BlockCodeBuilderImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java
! src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java

Changeset: c7d15f1f
Branch: premain
Author:    Attila Szegedi <attila at openjdk.org>
Date:      2024-09-04 13:40:40 +0000
URL:       https://git.openjdk.org/leyden/commit/c7d15f1fe09e61c1e61ee253e7e3df4c2b9306a1

8325679: Optimize ArrayList subList sort

Reviewed-by: liach

! src/java.base/share/classes/java/util/ArrayList.java
! test/jdk/java/util/List/ListDefaults.java

Changeset: 6f8714ee
Branch: premain
Author:    Jasmine Karthikeyan <jkarthikeyan at openjdk.org>
Date:      2024-09-04 13:44:24 +0000
URL:       https://git.openjdk.org/leyden/commit/6f8714ee197eb48923209299fd842f6757f0a945

8336860: x86: Change integer src operand for CMoveL of 0 and 1 to long

Reviewed-by: epeter, chagedorn, shade, qamai, jbhateja

! src/hotspot/cpu/x86/x86_64.ad
+ test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java
! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java
! test/micro/org/openjdk/bench/vm/compiler/x86/BasicRules.java

Changeset: 0cfd08f5
Branch: premain
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-09-04 15:48:32 +0000
URL:       https://git.openjdk.org/leyden/commit/0cfd08f55aa166dc3f027887c886fa0b40a2ca21

8339112: Move JVM Klass flags out of AccessFlags

Reviewed-by: matsaave, cjplummer, dlong, thartmann, yzheng

! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp
! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
! src/hotspot/cpu/arm/c1_Runtime1_arm.cpp
! src/hotspot/cpu/arm/c2_MacroAssembler_arm.cpp
! src/hotspot/cpu/arm/interp_masm_arm.cpp
! src/hotspot/cpu/arm/templateTable_arm.cpp
! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/c1_Runtime1_ppc.cpp
! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
! src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/c1_Runtime1_riscv.cpp
! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/interp_masm_riscv.cpp
! src/hotspot/cpu/riscv/templateTable_riscv.cpp
! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
! src/hotspot/cpu/s390/c1_Runtime1_s390.cpp
! src/hotspot/cpu/s390/interp_masm_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.cpp
! src/hotspot/cpu/s390/templateTable_s390.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/interp_masm_x86.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/share/ci/ciInstanceKlass.cpp
! src/hotspot/share/ci/ciKlass.cpp
! src/hotspot/share/ci/ciKlass.hpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/oops/klass.hpp
! src/hotspot/share/oops/klass.inline.hpp
+ src/hotspot/share/oops/klassFlags.cpp
+ src/hotspot/share/oops/klassFlags.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/library_call.hpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/hotspot/share/utilities/accessFlags.hpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/AccessFlags.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Klass.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfig.java

Changeset: 12d060a2
Branch: premain
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2024-09-04 16:21:19 +0000
URL:       https://git.openjdk.org/leyden/commit/12d060a255b9b783488714c6c2cb73a899d3f708

8339148: Make os::Linux::active_processor_count() public

Reviewed-by: dholmes, jwaters

! src/hotspot/os/linux/os_linux.hpp

Changeset: ef96a7b0
Branch: premain
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-09-04 16:37:17 +0000
URL:       https://git.openjdk.org/leyden/commit/ef96a7b014795f366af3a90ef8f474cfb621197f

8332901: Select{Current,New}ItemTest.java for Choice don't open popup on macOS

Move SelectCurrentItemTest.java to java/awt/Choice/SelectItem/.
Move SelectNewItemTest.java to java/awt/Choice/SelectItem/.
Use latches to control test flow instead of delays.
Encapsulate the common logic in SelectCurrentItemTest.
Provide overridable checkXXX() methods to modify conditions.
Provide an overridable method which defines where to click
in the choice popup to select an item.

Reviewed-by: honkar, prr, dnguyen

! test/jdk/ProblemList.txt
- test/jdk/java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java
+ test/jdk/java/awt/Choice/SelectItem/SelectCurrentItemTest.java
+ test/jdk/java/awt/Choice/SelectItem/SelectNewItemTest.java
- test/jdk/java/awt/Choice/SelectNewItemTest/SelectNewItemTest.java

Changeset: 433f6d8a
Branch: premain
Author:    David M. Lloyd <david.lloyd at redhat.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-09-04 16:46:44 +0000
URL:       https://git.openjdk.org/leyden/commit/433f6d8a0643b59663bf76c0f3a2af27a6cc56b7

8339492: StackMapDecoder::writeFrames makes lots of allocations

Reviewed-by: liach, redestad, jwaters, asotona

! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java

Changeset: 1353601d
Branch: premain
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-09-04 17:25:37 +0000
URL:       https://git.openjdk.org/leyden/commit/1353601dcc8f9ec3e12dea21dc61b3585a154b13

8338924: C1: assert(0 <= i && i < _len) failed: illegal index 5 for length 5

Co-authored-by: Dean Long <dlong at openjdk.org>
Reviewed-by: kvn, thartmann

! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/compiler/methodLiveness.cpp
! test/hotspot/jtreg/ProblemList-Xcomp.txt
! test/hotspot/jtreg/runtime/interpreter/LastJsrTest.java

Changeset: b8d560b6
Branch: premain
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Harshitha Onkar <honkar at openjdk.org>
Date:      2024-09-04 20:05:27 +0000
URL:       https://git.openjdk.org/leyden/commit/b8d560b6cd9ea35c747487017107a6caeacf8a98

8339233: Test javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java#id failed: Button renderings are different after window resize

Reviewed-by: honkar

! test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java

Changeset: d4dfa012
Branch: premain
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-09-04 20:49:32 +0000
URL:       https://git.openjdk.org/leyden/commit/d4dfa0127f4d51c8127c5d4dfe3b58c09500e80f

8338530: CDS warning Skipping java/lang/invoke/BoundMethodHandle$Species_LLLL

Reviewed-by: iklam, ccheung

! src/hotspot/share/classfile/systemDictionaryShared.cpp
! test/hotspot/jtreg/runtime/cds/appcds/jvmti/dumpingWithAgent/DumpingWithJavaAgent.java

Changeset: 55312e15
Branch: premain
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-09-04 22:45:17 +0000
URL:       https://git.openjdk.org/leyden/commit/55312e1549c36be46b0f3b3b40763a33311c3e25

8338937: Optimize the string concatenation of ClassDesc

Reviewed-by: liach

! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/StringConcatHelper.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/constant/ClassDesc.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java

Changeset: 96df5a6d
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-09-04 23:58:17 +0000
URL:       https://git.openjdk.org/leyden/commit/96df5a6d8f90c988b354dbe6bdc510aa4b8ee98b

8339316: Test runtime/exceptionMsgs/NoClassDefFoundError/NoClassDefFoundErrorTest.java fails after  JDK-8338257

Reviewed-by: jsjolen, coleenp

! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/prims/jniCheck.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/utilities/exceptions.cpp
! test/hotspot/jtreg/ProblemList.txt

Changeset: 28de44da
Branch: premain
Author:    Amit Kumar <amitkumar at openjdk.org>
Date:      2024-09-05 07:01:29 +0000
URL:       https://git.openjdk.org/leyden/commit/28de44da71871bec7648f01a4df2faee43fa43b6

8332461: ubsan : dependencies.cpp:906:3: runtime error: load of value 4294967295, which is not a valid value for type 'DepType'

Reviewed-by: stefank, kvn, dlong

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

Changeset: 96a0502d
Branch: premain
Author:    Ivan Walulya <iwalulya at openjdk.org>
Date:      2024-09-05 08:18:35 +0000
URL:       https://git.openjdk.org/leyden/commit/96a0502d624e3eff1b00a7c63e8b3a27870b475e

8339369: G1: TestVerificationInConcurrentCycle.java fails with "Missing rem set entry" when using "-XX:G1RSetUpdatingPauseTimePercent=0 -XX:G1UpdateBufferSize=2"

Reviewed-by: tschatzl, kbarrett

! src/hotspot/share/gc/g1/g1FullCollector.cpp
! src/hotspot/share/gc/g1/g1FullGCResetMetadataTask.cpp

Changeset: 2305d18e
Branch: premain
Author:    Yagmur Eren <yagmur.eren at oracle.com>
Date:      2024-09-05 09:26:08 +0000
URL:       https://git.openjdk.org/leyden/commit/2305d18e8d53dbbf341b580b60f9ed21f408bff1

8339384: Unintentional IOException in jdk.jdi module when JDWP end of stream occurs

Reviewed-by: cjplummer, kevinw

! src/jdk.jdi/share/classes/com/sun/tools/jdi/TargetVM.java

Changeset: 340e131d
Branch: premain
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-09-05 10:52:44 +0000
URL:       https://git.openjdk.org/leyden/commit/340e131d616bd81ccd0bdc3817aead0284014cac

8338971: IGV: Add incrementally inlined method name to phase name

Reviewed-by: rcastanedalo, kvn

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

Changeset: cb9f5c57
Branch: premain
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
Date:      2024-09-05 11:45:49 +0000
URL:       https://git.openjdk.org/leyden/commit/cb9f5c5791d17afbf72f7debe8013b77e45b3b56

8339290: Optimize ClassFile Utf8EntryImpl#writeTo

Reviewed-by: redestad, liach

! src/java.base/share/classes/java/lang/StringCoding.java
! 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/classfile/impl/AbstractPoolEntry.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java
+ test/jdk/java/lang/String/CountNonZeroAscii.java
+ test/micro/org/openjdk/bench/java/lang/classfile/Utf8EntryWriteTo.java

Changeset: 6be92726
Branch: premain
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-09-05 13:10:24 +0000
URL:       https://git.openjdk.org/leyden/commit/6be927260a84b1d7542167e526ff41f7dc26cab0

8338591: Improve performance of MemorySegment::copy

Reviewed-by: mcimadamore

! src/java.base/share/classes/java/lang/foreign/MemorySegment.java
! src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
! test/jdk/java/foreign/TestSegmentCopy.java
+ test/micro/org/openjdk/bench/java/lang/foreign/CopyTest.java

Changeset: a505a1dd
Branch: premain
Author:    Fernando Guallini <fguallini at openjdk.org>
Committer: Sean Mullan <mullan at openjdk.org>
Date:      2024-09-05 13:14:00 +0000
URL:       https://git.openjdk.org/leyden/commit/a505a1dda3bc6975bb11f390543b38618ddf2626

8337951: Test sun/security/validator/samedn.sh CertificateNotYetValidException: NotBefore validation

Reviewed-by: mullan

! test/jdk/sun/security/validator/samedn.sh

Changeset: ab656c3a
Branch: premain
Author:    Joel Sikstr?m <joel.sikstrom at oracle.com>
Committer: Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-05 13:39:56 +0000
URL:       https://git.openjdk.org/leyden/commit/ab656c3aab8157ed8e70bc126881cbadc825de93

8339579: ZGC: Race results in only one of two remembered sets being cleared

Reviewed-by: stefank, sjohanss

! src/hotspot/share/gc/z/zRememberedSet.cpp

Changeset: b389bb45
Branch: premain
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-05 13:49:17 +0000
URL:       https://git.openjdk.org/leyden/commit/b389bb456726184e4691777b1bb02d4b8a8a3f97

8339540: Unify include requirements for PlatformMonitor/Mutex constructors/destructors

Reviewed-by: coleenp, sjohanss

! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/os/windows/os_windows.inline.hpp

Changeset: 042053c3
Branch: premain
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-09-05 15:03:54 +0000
URL:       https://git.openjdk.org/leyden/commit/042053c3a82e9fbd4c6866efe872c1c92714e6e7

8003887: File.getCanonicalFile() does not resolve symlinks on MS Windows

Reviewed-by: alanb

! src/java.base/windows/classes/java/io/WinNTFileSystem.java
! src/java.base/windows/native/libjava/WinNTFileSystem_md.c
! test/jdk/java/io/File/GetCanonicalPath.java

Changeset: 4ffcf894
Branch: premain
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2024-09-05 15:12:27 +0000
URL:       https://git.openjdk.org/leyden/commit/4ffcf894b5937d6c6914b8f24caead87bd3e4228

8339619: ProblemList runtime/cds/appcds/jvmti/dumpingWithAgent/DumpingWithJavaAgent.java

Reviewed-by: azvegint

! test/hotspot/jtreg/ProblemList.txt

Changeset: 59c4649b
Branch: premain
Author:    Artur Barashev <artur.barashev at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
Date:      2024-09-05 15:34:26 +0000
URL:       https://git.openjdk.org/leyden/commit/59c4649be37a387efaf100f368b3e9db06d44f3a

8329959: Update DigestMD5Client.java - fix typo in javadoc string

Reviewed-by: weijun

! src/java.security.sasl/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java

Changeset: b895d7cf
Branch: premain
Author:    Suchismith Roy <sroy at openjdk.org>
Committer: Martin Doerr <mdoerr at openjdk.org>
Date:      2024-09-05 15:44:57 +0000
URL:       https://git.openjdk.org/leyden/commit/b895d7cf9fe0370a919e7092e40ac3458d91e95e

8332423: [PPC64] Remove C1_MacroAssembler::call_c_with_frame_resize

Reviewed-by: mdoerr, varadam

! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp
! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.hpp
! src/hotspot/cpu/ppc/c1_Runtime1_ppc.cpp
! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp
! src/hotspot/cpu/ppc/runtime_ppc.cpp
! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp

Changeset: 98020e47
Branch: premain
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2024-09-05 15:46:38 +0000
URL:       https://git.openjdk.org/leyden/commit/98020e47996c0c6870e406bd513c8f503a336a73

8338133: Cleanup direct use of `new HtmlTree`

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlLinkFactory.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexRedirectWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SearchWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerialFieldWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerialMethodWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TableOfContents.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Head.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/SnippetTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlTree.java
! test/langtools/jdk/javadoc/doclet/testHtmlDocument/TestHtmlDocument.java
! test/langtools/jdk/javadoc/doclet/testVoidHtmlElements/TestVoidHtmlElements.java

Changeset: e203df46
Branch: premain
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2024-09-05 15:51:27 +0000
URL:       https://git.openjdk.org/leyden/commit/e203df46faf610e35e2c2510271ad68199f4fa3f

8338100: C2: assert(!n_loop->is_member(get_loop(lca))) failed: control must not be back in the loop

Co-authored-by: Emanuel Peter <epeter at openjdk.org>
Reviewed-by: chagedorn, thartmann

! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/loopnode.hpp
! src/hotspot/share/opto/parse1.cpp
+ test/hotspot/jtreg/compiler/loopopts/LongCountedLoopInInfiniteLoop.jasm
+ test/hotspot/jtreg/compiler/loopopts/MoveStoreAfterInfiniteLoop.jasm
+ test/hotspot/jtreg/compiler/loopopts/TestLongCountedLoopInInfiniteLoop.java
+ test/hotspot/jtreg/compiler/loopopts/TestMoveStoreAfterInfiniteLoop.java

Changeset: 48d79431
Branch: premain
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-09-05 16:34:39 +0000
URL:       https://git.openjdk.org/leyden/commit/48d79431c95759954f6dd283de78fe9f9fe9370a

8339342: FieldAllocationCount is mostly unused

Reviewed-by: fparain, stuefe, matsaave

! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/classFileParser.hpp

Changeset: 9e1af8cc
Branch: premain
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-09-05 18:11:18 +0000
URL:       https://git.openjdk.org/leyden/commit/9e1af8cc7cc9f63453097bd35eb3cf29f945d765

8339285: Test fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames

Reviewed-by: alanb

! src/java.base/aix/native/libnio/MappedMemoryUtils.c
! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
! src/java.base/share/classes/java/nio/MappedMemoryUtils.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/unix/native/libnio/MappedMemoryUtils.c
! src/java.base/windows/native/libnio/MappedMemoryUtils.c
+ test/jdk/java/foreign/TestMappedHandshake.java

Changeset: 8fb8cd85
Branch: premain
Author:    Hai-May Chao <hchao at openjdk.org>
Date:      2024-09-05 20:17:52 +0000
URL:       https://git.openjdk.org/leyden/commit/8fb8cd85b7bd2e004329b4968f9564f340002cc1

8339347: keytool -importpass insists prompting the user even if there is no terminal

Reviewed-by: weijun

! src/java.base/share/classes/sun/security/tools/keytool/Main.java
+ test/jdk/sun/security/tools/keytool/TestImportPass.java

Changeset: 9e0ccb8b
Branch: premain
Author:    Fei Yang <fyang at openjdk.org>
Date:      2024-09-06 02:01:43 +0000
URL:       https://git.openjdk.org/leyden/commit/9e0ccb8bbd01ffbac466288977a770dd09e357af

8339548: GHA: RISC-V: Use Debian snapshot archive for bootstrap

Reviewed-by: shade, erikj

! .github/workflows/build-cross-compile.yml

Changeset: 7db4d46c
Branch: premain
Author:    nelanbu <yagmur.eren at oracle.com>
Committer: Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-09-06 06:44:54 +0000
URL:       https://git.openjdk.org/leyden/commit/7db4d46c3904d1a6949f053e6fc5e971cd519088

8330159: [C2] Remove or clarify Compile::init_start

Reviewed-by: chagedorn, dlong

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

Changeset: a35fd386
Branch: premain
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-09-06 07:43:38 +0000
URL:       https://git.openjdk.org/leyden/commit/a35fd3861044bdb8ddae378cb666b3d2e549a8c8

8339368: Switch targets are not inflated in CodeModel if no StackMap

Reviewed-by: liach

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

Changeset: a1eebbdf
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-06 11:42:50 +0000
URL:       https://git.openjdk.org/leyden/commit/a1eebbdf8a62b641b765bf4cec5066690c11a8e5

8339576: Speed up raw bytecode processing in ClassFile API

Co-authored-by: Shaojin Wen <swen at openjdk.org>
Reviewed-by: asotona, redestad

! src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java
! src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java
! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java
! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerificationBytecodes.java
! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java
! test/jdk/jdk/classfile/UtilTest.java
! test/micro/org/openjdk/bench/jdk/classfile/CodeAttributeTools.java

Changeset: febbd998
Branch: premain
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-09-06 12:01:01 +0000
URL:       https://git.openjdk.org/leyden/commit/febbd998ee72054353e816e9b7b588c9ea2c0500

8339168: Optimize ClassFile Util slotSize

Reviewed-by: liach, redestad

! src/java.base/share/classes/jdk/internal/classfile/impl/DirectMethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java

Changeset: 260908e1
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-06 12:04:38 +0000
URL:       https://git.openjdk.org/leyden/commit/260908e16ece7a0a9e6f538273b27c677db4d296

8339592: Simplify and remove unused code in ObjectMethods.<clinit>

Reviewed-by: liach

! src/java.base/share/classes/java/lang/runtime/ObjectMethods.java

Changeset: cb00333d
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-06 12:27:53 +0000
URL:       https://git.openjdk.org/leyden/commit/cb00333d6a47760cb2ab17e867ea8dab32289f98

8339640: Reduce construction overheads in StringConcatFactory$InlineHiddenClassStrategy

Reviewed-by: liach

! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java

Changeset: d2b36f09
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-06 12:37:48 +0000
URL:       https://git.openjdk.org/leyden/commit/d2b36f09072e03370ee02b063fcc4a1f0e6cb2ee

8339642: Reduce overheads in InvokerBytecodeGenerator

Reviewed-by: liach

! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/LambdaForm.java

Changeset: 9ebc2ecb
Branch: premain
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-09-06 13:38:22 +0000
URL:       https://git.openjdk.org/leyden/commit/9ebc2ecbf613da3bcee1dd5e8920a26d5f6d6df7

8339317: Optimize ClassFile writeBuffer

Reviewed-by: redestad, liach

! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractAttributeMapper.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectClassBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java
! src/java.base/share/classes/jdk/internal/classfile/impl/UnboundAttribute.java

Changeset: 17571b6d
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-09-25 22:34:31 +0000
URL:       https://git.openjdk.org/leyden/commit/17571b6d09fc5352784e2fb5f2f6817ea38eff40

Merge branch 'master' into premain

! make/InitSupport.gmk
! 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/ppc/templateInterpreterGenerator_ppc.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/ci/ciInstanceKlass.cpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciMethod.hpp
! src/hotspot/share/classfile/compactHashtable.hpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/classfile/modules.cpp
! src/hotspot/share/classfile/stringTable.cpp
! src/hotspot/share/classfile/symbolTable.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/vmClassMacros.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/dependencies.cpp
! src/hotspot/share/code/dependencies.hpp
! src/hotspot/share/compiler/compilationPolicy.cpp
! src/hotspot/share/compiler/compilerDefinitions.hpp
! src/hotspot/share/compiler/disassembler.cpp
! src/hotspot/share/include/jvm.h
! src/hotspot/share/memory/metadataFactory.hpp
! src/hotspot/share/memory/metaspace.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/oops/klass.hpp
! src/hotspot/share/oops/klass.inline.hpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/jvmtiEnv.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/java.hpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/threads.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/LambdaForm.java
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/runtime/cds/appcds/TestParallelGCWithCDS.java
! make/InitSupport.gmk
! 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/ppc/templateInterpreterGenerator_ppc.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/ci/ciInstanceKlass.cpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciMethod.hpp
! src/hotspot/share/classfile/compactHashtable.hpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/classfile/modules.cpp
! src/hotspot/share/classfile/stringTable.cpp
! src/hotspot/share/classfile/symbolTable.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/vmClassMacros.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
+ src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/dependencies.cpp
! src/hotspot/share/code/dependencies.hpp
! src/hotspot/share/compiler/compilationPolicy.cpp
! src/hotspot/share/compiler/compilerDefinitions.hpp
! src/hotspot/share/compiler/disassembler.cpp
! src/hotspot/share/include/jvm.h
! src/hotspot/share/memory/metadataFactory.hpp
! src/hotspot/share/memory/metaspace.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/oops/klass.hpp
! src/hotspot/share/oops/klass.inline.hpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/jvmtiEnv.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/java.hpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/threads.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/LambdaForm.java
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/runtime/cds/appcds/TestParallelGCWithCDS.java

Changeset: 0df10bbd
Branch: premain
Author:    Andrew Dinn <adinn at openjdk.org>
Date:      2024-09-06 13:57:13 +0000
URL:       https://git.openjdk.org/leyden/commit/0df10bbd96df46f23a7f57e5b9455fea41b2b15b

8339466: Enumerate shared stubs and define static fields and names via declarations

Reviewed-by: kvn, fyang

! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/arm/sharedRuntime_arm.cpp
! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp
! src/hotspot/cpu/s390/sharedRuntime_s390.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/zero/sharedRuntime_zero.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/sharedRuntime.hpp
+ src/hotspot/share/runtime/stubDeclarations.hpp

Changeset: 5b72bbf9
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-06 14:57:12 +0000
URL:       https://git.openjdk.org/leyden/commit/5b72bbf9d4a4c9c966a665c8d48e5f6c0dcdba1c

8339519: Remove size field from instructions

Reviewed-by: asotona

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

Changeset: 8e580ec5
Branch: premain
Author:    Jorn Vernee <jvernee at openjdk.org>
Date:      2024-09-06 17:32:34 +0000
URL:       https://git.openjdk.org/leyden/commit/8e580ec5382af1886e1bbf2fda3bce6416ced604

8338123: Linker crash when building a downcall handle with many arguments in x64

Reviewed-by: mcimadamore

! src/hotspot/cpu/x86/downcallLinker_x86_64.cpp
! test/jdk/java/foreign/largestub/TestLargeStub.java

Changeset: fbe26293
Branch: premain
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-09-06 18:37:29 +0000
URL:       https://git.openjdk.org/leyden/commit/fbe2629303bcee5855673b7e37d8c49f19dc9849

8339635: StringConcatFactory optimization for CompactStrings off

Reviewed-by: liach

! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java

Changeset: deeb09a6
Branch: premain
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2024-09-07 05:46:47 +0000
URL:       https://git.openjdk.org/leyden/commit/deeb09a640bf693ea130d1283fc010c22f0cf9db

8339307: jhsdb jstack could not trace FFM upcall frame

Reviewed-by: cjplummer, jvernee

! src/hotspot/share/code/codeBlob.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java
+ src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/UpcallStub.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java
+ test/hotspot/jtreg/serviceability/sa/LingeredAppWithFFMUpcall.java
+ test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackUpcall.java
+ test/hotspot/jtreg/serviceability/sa/libupcall.c

Changeset: f0e84b76
Branch: premain
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-09-07 22:20:37 +0000
URL:       https://git.openjdk.org/leyden/commit/f0e84b7617aebc421483f36bb7d0b14d0fc39616

8339703: Problem list serviceability/sa/TestJhsdbJstackUpcall.java for generational ZGC

Reviewed-by: dholmes

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

Changeset: 79d76135
Branch: premain
Author:    Tejesh R <tr at openjdk.org>
Date:      2024-09-09 05:17:09 +0000
URL:       https://git.openjdk.org/leyden/commit/79d761358c5ee19b9028ad89d7c6a33dff6aa64a

8338153: java/awt/Checkbox/CheckboxCheckerScalingTest.java test failed on linux machine

Reviewed-by: abhiscxk, honkar

! test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java

Changeset: a18d9d84
Branch: premain
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-09-09 05:34:09 +0000
URL:       https://git.openjdk.org/leyden/commit/a18d9d84cd92b0b7e7c3c83efab1d81773e3a87c

8326616: tools/javac/patterns/Exhaustiveness.java intermittently Timeout signalled after 480 seconds

Reviewed-by: abimpoudis

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
! test/langtools/ProblemList.txt

Changeset: b45fe174
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-09 05:53:29 +0000
URL:       https://git.openjdk.org/leyden/commit/b45fe174500f4bc38a0bb703c81614355404ae4f

8339710: Avoid initializing AccessFlag related classes in write-only cases

Reviewed-by: liach

! src/java.base/share/classes/jdk/internal/classfile/impl/DirectClassBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectFieldBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectMethodBuilder.java

Changeset: cb5c60b5
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-09-09 06:42:05 +0000
URL:       https://git.openjdk.org/leyden/commit/cb5c60b530dd744e7d78ef69f15eef7521c4f1cc

8339591: Mark jdk/jshell/ExceptionMessageTest.java intermittent

Reviewed-by: lucy

! test/langtools/jdk/jshell/ExceptionMessageTest.java

Changeset: 4ff72dc5
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-09-09 07:35:18 +0000
URL:       https://git.openjdk.org/leyden/commit/4ff72dc57e65e99b129f0ba28196994edf402018

8339487: ProcessHandleImpl os_getChildren sysctl call - retry in case of ENOMEM and enhance exception message

Reviewed-by: alanb, lucy, rriggs

! src/java.base/macosx/native/libjava/ProcessHandleImpl_macosx.c
! src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c

Changeset: 347d5728
Branch: premain
Author:    Stefan Johansson <sjohanss at openjdk.org>
Date:      2024-09-09 11:14:26 +0000
URL:       https://git.openjdk.org/leyden/commit/347d5728e69ae1f7d1a24820cc2c17bb0b8c0af5

8339387: ZGC: Synchronize medium page allocation

Reviewed-by: aboldtch, stefank, eosterlund

! src/hotspot/share/gc/z/zObjectAllocator.cpp
! src/hotspot/share/gc/z/zObjectAllocator.hpp

Changeset: 615a24f2
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-09 11:56:34 +0000
URL:       https://git.openjdk.org/leyden/commit/615a24f216b80944fcef7eb5dd1c0c2fb4b45385

8338902: CDS flags are reported with wrong flag category

Reviewed-by: iklam, adinn

! src/hotspot/share/runtime/flags/allFlags.hpp

Changeset: 88cccc14
Branch: premain
Author:    Pavel Rappo <prappo at openjdk.org>
Date:      2024-09-09 12:06:21 +0000
URL:       https://git.openjdk.org/leyden/commit/88cccc14db168876a60b5ea2ae9d0fda7969af9a

8339631: Fix block @jls and @jvms tags

Reviewed-by: liach, darcy, jjg

! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/lang/Double.java
! src/java.base/share/classes/java/lang/Record.java
! src/java.base/share/classes/java/lang/StackWalker.java
! src/java.base/share/classes/java/lang/constant/PackageDesc.java
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/lang/reflect/AccessFlag.java
! src/java.base/share/classes/java/lang/reflect/InvocationHandler.java
! src/java.base/share/classes/java/lang/reflect/Method.java
! src/java.compiler/share/classes/javax/lang/model/element/NestingKind.java
! src/java.compiler/share/classes/javax/lang/model/type/NullType.java
! src/java.compiler/share/classes/javax/lang/model/type/TypeVariable.java
! src/jdk.compiler/share/classes/com/sun/source/tree/ClassTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/InstanceOfTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/LiteralTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/MethodTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/ModifiersTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/StatementTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/SwitchExpressionTree.java
! src/jdk.compiler/share/classes/com/sun/source/tree/VariableTree.java
! src/jdk.jshell/share/classes/jdk/jshell/Snippet.java

Changeset: c54fc08a
Branch: premain
Author:    Ferenc Rakoczi <ferenc.r.rakoczi at oracle.com>
Date:      2024-09-09 13:49:34 +0000
URL:       https://git.openjdk.org/leyden/commit/c54fc08aa3c63e4b26dc5edb2436844dfd3bab7c

8338587: Internal XOF Methods for SHAKE128 and SHAKE256

Reviewed-by: valeriep, weijun

! src/java.base/share/classes/sun/security/ec/ed/EdDSAParameters.java
! src/java.base/share/classes/sun/security/pkcs/PKCS7.java
! src/java.base/share/classes/sun/security/pkcs/SignerInfo.java
! src/java.base/share/classes/sun/security/provider/SHA3.java
- src/java.base/share/classes/sun/security/provider/SHAKE128.java
- src/java.base/share/classes/sun/security/provider/SHAKE256.java
! test/jdk/sun/security/ec/ed/TestEdOps.java
+ test/jdk/sun/security/provider/MessageDigest/SHAKEsqueeze.java
! test/lib/jdk/test/lib/security/SeededSecureRandom.java

Changeset: d53e405a
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-09 14:18:20 +0000
URL:       https://git.openjdk.org/leyden/commit/d53e405a26e53086d46ce78a9792f0ca72cca529

8339742: Refactor ClassFileImpl to allow loading Option classes lazily

Reviewed-by: asotona

! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractDirectBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java

Changeset: 7c0f013d
Branch: premain
Author:    Oli Gillespie <ogillespie at openjdk.org>
Date:      2024-09-09 14:53:36 +0000
URL:       https://git.openjdk.org/leyden/commit/7c0f013d924a66c9cf55de761702b8de855e87fa

8339488: Extended NPE message doesn't handle CONSTANT_Dynamic

Reviewed-by: lmesnik, coleenp, simonis, liach

! src/hotspot/share/interpreter/bytecodeUtils.cpp
+ test/hotspot/jtreg/runtime/condy/CondyExtendedNullPointer.jasm
+ test/hotspot/jtreg/runtime/condy/CondyExtendedNullPointerTest.java

Changeset: a9bb0433
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-09 15:15:16 +0000
URL:       https://git.openjdk.org/leyden/commit/a9bb04331df6788561921202cac73e35afbfe314

8339683: Simplify class data generation in InvokerBytecodeGenerator

Reviewed-by: redestad

! src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java

Changeset: 86a2f9c7
Branch: premain
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-09-09 16:04:59 +0000
URL:       https://git.openjdk.org/leyden/commit/86a2f9c7dcb6585cabf03c0940511d11560e85b7

8339644: Improve parsing of Day/Month in tzdata rules

Reviewed-by: jlu, coffeys

! make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java
! test/jdk/sun/util/calendar/zi/Month.java
! test/jdk/sun/util/calendar/zi/RuleDay.java

Changeset: 77468c28
Branch: premain
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-09-09 16:28:17 +0000
URL:       https://git.openjdk.org/leyden/commit/77468c284c068f921da543edd28333911e915b61

8339575: DumpingWithJavaAgent.java failed with missing expected output

Reviewed-by: ccheung, dholmes

! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/runtime/cds/appcds/StaticArchiveWithLambda.java
! test/hotspot/jtreg/runtime/cds/appcds/jvmti/dumpingWithAgent/DumpingWithJavaAgent.java

Changeset: 6b5958d6
Branch: premain
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-09-09 19:24:33 +0000
URL:       https://git.openjdk.org/leyden/commit/6b5958d6612a57c48320438981b2eae030927065

8339696: Clarify modeling scope of javax.lang.model.element

Reviewed-by: jjg, jlahoda, prappo

! src/java.compiler/share/classes/javax/lang/model/element/package-info.java

Changeset: 559fc711
Branch: premain
Author:    Evgeny Nikitin <enikitin at openjdk.org>
Committer: Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-09-09 19:55:45 +0000
URL:       https://git.openjdk.org/leyden/commit/559fc711e03cf0086bea399ffb40cf294cbbb6e1

8339366: [jittester] Make it possible to generate tests without execution

Reviewed-by: lmesnik

! test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/Automatic.java
! test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/ByteCodeGenerator.java
+ test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/IRTreeGenerator.java
! test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/JavaCodeGenerator.java
! test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/ProductionParams.java
! test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/TestsGenerator.java
! test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/utils/OptionResolver.java

Changeset: 56387a09
Branch: premain
Author:    Artur Barashev <artur.barashev at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
Date:      2024-09-09 21:04:04 +0000
URL:       https://git.openjdk.org/leyden/commit/56387a09810a3204ed820885e0ff0b26408be59d

8329754: The ThreadSafe attribute is ignored for SecureRandom algorithm aliases

Reviewed-by: weijun

! src/java.base/share/classes/java/security/SecureRandom.java
! test/jdk/java/security/SecureRandom/ThreadSafe.java

Changeset: 5e822c24
Branch: premain
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-09-10 06:13:36 +0000
URL:       https://git.openjdk.org/leyden/commit/5e822c24bb42e9027c8d9090d498bca7125d1963

8334870: javac does not accept classfiles with certain permitted RuntimeVisibleParameterAnnotations and RuntimeInvisibleParameterAnnotations attributes

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
- test/langtools/tools/javac/T6435291/T.jcod
- test/langtools/tools/javac/T6435291/T6435291.java
+ test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
! test/langtools/tools/javac/diags/examples.not-yet.txt

Changeset: 7e2bcf6d
Branch: premain
Author:    Alan Bateman <alanb at openjdk.org>
Date:      2024-09-10 07:23:35 +0000
URL:       https://git.openjdk.org/leyden/commit/7e2bcf6d0010161dfbc50da4031e65cb5482fb77

8338890: Add monitoring/management interface for the virtual thread scheduler

Reviewed-by: kevinw

! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/VirtualThread.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/share/classes/module-info.java
! src/jdk.management/share/classes/com/sun/management/internal/PlatformMBeanProviderImpl.java
+ src/jdk.management/share/classes/com/sun/management/internal/VirtualThreadSchedulerImpls.java
! src/jdk.management/share/classes/com/sun/management/package-info.java
+ src/jdk.management/share/classes/jdk/management/VirtualThreadSchedulerMXBean.java
+ src/jdk.management/share/classes/jdk/management/package-info.java
! src/jdk.management/share/classes/module-info.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/VThreadEventTest.java
! test/jdk/TEST.groups
! test/jdk/java/lang/Thread/virtual/JfrEvents.java
! test/jdk/java/lang/Thread/virtual/MonitorEnterExit.java
! test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java
! test/jdk/java/lang/Thread/virtual/ThreadAPI.java
! test/jdk/java/lang/Thread/virtual/VirtualThreadPinnedEventThrows.java
! test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking.java
! test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java
! test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java
+ test/jdk/jdk/management/VirtualThreadSchedulerMXBean/VirtualThreadSchedulerMXBeanTest.java
! test/lib/jdk/test/lib/thread/VThreadRunner.java

Changeset: 125f7432
Branch: premain
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-09-10 08:14:40 +0000
URL:       https://git.openjdk.org/leyden/commit/125f743223f2beb6e73f520c48a9a2de7ba5dce7

8305489: runtime/ErrorHandling/TestDwarf.java fails in some Linux configurations after JDK-8303805

Reviewed-by: dholmes, lmesnik

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

Changeset: 64de7813
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-09-10 08:22:25 +0000
URL:       https://git.openjdk.org/leyden/commit/64de7813e4403f669fe9c02eabb204802f131367

8339587: runtime/reflect/ReflectOutOfMemoryError.java fails with "bootstrap method initialization exception"

Reviewed-by: lmesnik, ccheung

! test/hotspot/jtreg/runtime/reflect/ReflectOutOfMemoryError.java

Changeset: 0d8e52b3
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-10 09:46:36 +0000
URL:       https://git.openjdk.org/leyden/commit/0d8e52b382432674533c9b80565eadf39ae83c64

8339800: Prefer invokeBasic in BootstrapMethodInvokers

Reviewed-by: jvernee

! src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java

Changeset: ad104932
Branch: premain
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-09-10 11:43:21 +0000
URL:       https://git.openjdk.org/leyden/commit/ad104932e6c26806c353ad048ce5cff7d2b4c29a

8338526: Don't store abstract and interface Klasses in class metaspace

Reviewed-by: stuefe, iklam

! src/hotspot/share/classfile/classFileParser.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdKlassQueue.cpp
! src/hotspot/share/memory/allocation.cpp
! src/hotspot/share/memory/metaspace.cpp
! src/hotspot/share/memory/metaspace.hpp
! src/hotspot/share/oops/annotations.hpp
! src/hotspot/share/oops/array.inline.hpp
! src/hotspot/share/oops/arrayKlass.cpp
! src/hotspot/share/oops/arrayKlass.hpp
! src/hotspot/share/oops/compressedKlass.hpp
! src/hotspot/share/oops/constMethod.hpp
! src/hotspot/share/oops/cpCache.hpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/oops/klass.hpp
! src/hotspot/share/oops/recordComponent.hpp
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! test/hotspot/jtreg/vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java

Changeset: 4d597de8
Branch: premain
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
Date:      2024-09-10 12:33:07 +0000
URL:       https://git.openjdk.org/leyden/commit/4d597de893dad79e74a280f3f9e82f0a14f9045d

8338930: StringConcatFactory hardCoded string concatenation strategy

Reviewed-by: redestad, liach

! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java

Changeset: fb51c1e5
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-10 12:34:51 +0000
URL:       https://git.openjdk.org/leyden/commit/fb51c1e57b9bba876b6b5370c53abbd3196b8b2d

8339837: Remove unused BootstrapMethodsInvokers.isLambdaMetafactoryCondyBSM

Reviewed-by: jvernee

! src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java

Changeset: 38441b3f
Branch: premain
Author:    Quan Anh Mai <qamai at openjdk.org>
Date:      2024-09-10 12:44:57 +0000
URL:       https://git.openjdk.org/leyden/commit/38441b3f2d0e735089c29a9a9ce441b2d7c75db1

8339677: [vectorapi] YYYXXXVector::withLaneHelper and laneHelper should use Double::doubleToRawLongBits/Float::floatToRawIntBits

Reviewed-by: psandoz

! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template
! test/jdk/jdk/incubator/vector/Byte128VectorTests.java
! test/jdk/jdk/incubator/vector/Byte256VectorTests.java
! test/jdk/jdk/incubator/vector/Byte512VectorTests.java
! test/jdk/jdk/incubator/vector/Byte64VectorTests.java
! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Double128VectorTests.java
! test/jdk/jdk/incubator/vector/Double256VectorTests.java
! test/jdk/jdk/incubator/vector/Double512VectorTests.java
! test/jdk/jdk/incubator/vector/Double64VectorTests.java
! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Float128VectorTests.java
! test/jdk/jdk/incubator/vector/Float256VectorTests.java
! test/jdk/jdk/incubator/vector/Float512VectorTests.java
! test/jdk/jdk/incubator/vector/Float64VectorTests.java
! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Int128VectorTests.java
! test/jdk/jdk/incubator/vector/Int256VectorTests.java
! test/jdk/jdk/incubator/vector/Int512VectorTests.java
! test/jdk/jdk/incubator/vector/Int64VectorTests.java
! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Long128VectorTests.java
! test/jdk/jdk/incubator/vector/Long256VectorTests.java
! test/jdk/jdk/incubator/vector/Long512VectorTests.java
! test/jdk/jdk/incubator/vector/Long64VectorTests.java
! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Short128VectorTests.java
! test/jdk/jdk/incubator/vector/Short256VectorTests.java
! test/jdk/jdk/incubator/vector/Short512VectorTests.java
! test/jdk/jdk/incubator/vector/Short64VectorTests.java
! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java
! test/jdk/jdk/incubator/vector/templates/Kernel-With-Op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Get-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-With-Op.template
! test/jdk/jdk/incubator/vector/templates/Unit-header.template

Changeset: c246ede1
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-10 13:33:19 +0000
URL:       https://git.openjdk.org/leyden/commit/c246ede163d675cfdacf741565195751981afb41

8339799: Reduce work done in j.l.invoke bytecode generators

Reviewed-by: liach

! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java

Changeset: 64a79d89
Branch: premain
Author:    Joakim Nordstr?m <jnordstrom at openjdk.org>
Date:      2024-09-10 13:49:13 +0000
URL:       https://git.openjdk.org/leyden/commit/64a79d898637e9255e6c1133dd684e272d84b95c

8335625: Update Javadoc for GetCpuLoad

Reviewed-by: alanb, kevinw

! src/jdk.management/share/classes/com/sun/management/OperatingSystemMXBean.java

Changeset: be0dca04
Branch: premain
Author:    Sandhya Viswanathan <sviswanathan at openjdk.org>
Date:      2024-09-10 15:53:23 +0000
URL:       https://git.openjdk.org/leyden/commit/be0dca046a43ecef2dcd012da6399cbed4cd0454

8339698: x86 unused andw/orw/xorw/addw encoding could be removed

Reviewed-by: kvn, jbhateja, qamai

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp

Changeset: 33525226
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-09-10 16:28:04 +0000
URL:       https://git.openjdk.org/leyden/commit/33525226b97c80bf08c2e1ab9566aff5ac851fea

8338894: Deprecate jhsdb debugd for removal

Reviewed-by: cjplummer, alanb

! src/jdk.hotspot.agent/doc/index.html
! src/jdk.hotspot.agent/doc/transported_core.html
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/DebugServer.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HotSpotAgent.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java
! test/lib/jdk/test/lib/process/OutputAnalyzer.java

Changeset: 92431049
Branch: premain
Author:    Jasmine Karthikeyan <jkarthikeyan at openjdk.org>
Date:      2024-09-10 16:52:59 +0000
URL:       https://git.openjdk.org/leyden/commit/92431049fd1838ced2019366b7ccb37547ae6127

8335444: Generalize implementation of AndNode mul_ring

Reviewed-by: chagedorn, qamai, dfenacci

! src/hotspot/share/opto/mulnode.cpp
! test/hotspot/jtreg/compiler/c2/irTests/AndINodeIdealizationTests.java
! test/hotspot/jtreg/compiler/c2/irTests/AndLNodeIdealizationTests.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicBooleanOpTest.java
! test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java

Changeset: c8e64cb7
Branch: premain
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-09-10 17:27:19 +0000
URL:       https://git.openjdk.org/leyden/commit/c8e64cb7a578f1a32b48f76649fe19900ba6d040

8283779: Clarify API documentation of NetworkInterface with respect to configuration changes

Reviewed-by: alanb, msheppar

! src/java.base/share/classes/java/net/NetworkInterface.java

Changeset: 30645f33
Branch: premain
Author:    Fernando Guallini <fguallini at openjdk.org>
Committer: Jamil Nimeh <jnimeh at openjdk.org>
Date:      2024-09-10 18:48:58 +0000
URL:       https://git.openjdk.org/leyden/commit/30645f3309c040deb5bef71b1bd349942b4aa076

8338395: Add test coverage for instantiating NativePRNG with SecureRandomParameters

Reviewed-by: jnimeh

! test/jdk/sun/security/provider/SecureRandom/StrongSecureRandom.java

Changeset: 6fd043f1
Branch: premain
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-09-10 19:37:38 +0000
URL:       https://git.openjdk.org/leyden/commit/6fd043f1e4423b61cb5b85af9380f75e6a3846a2

8339789: Use index and definition tags in AnnotatedElement

Reviewed-by: jjg, prappo

! src/java.base/share/classes/java/lang/reflect/AnnotatedElement.java

Changeset: 9785e19f
Branch: premain
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-09-10 21:43:19 +0000
URL:       https://git.openjdk.org/leyden/commit/9785e19f3f87306cabc26a862d35b89d41cfef93

8339638: Update vmTestbase/nsk/jvmti/*Field*Watch tests to use virtual thread factory

Reviewed-by: cjplummer, sspitsyn

! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldAccessWatch/clrfldw001.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldModificationWatch/clrfmodw001.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001.java
+ test/lib/jdk/test/lib/thread/TestThreadFactory.java

Changeset: 07643237
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-11 01:19:15 +0000
URL:       https://git.openjdk.org/leyden/commit/07643237d4a9c2da8a43dbdf0c6b32215827b741

8225049: Bad -Xlog example in -Xlog:help, online documentation, JEP

Reviewed-by: dholmes

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

Changeset: a6faf824
Branch: premain
Author:    SendaoYan <syan at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
Date:      2024-09-11 02:12:08 +0000
URL:       https://git.openjdk.org/leyden/commit/a6faf8247b58d73dca199fe1e8b0e914c415f67f

8339714: Delete tedious bool type define

Reviewed-by: jwaters, dholmes

! src/java.base/unix/native/libjsig/jsig.c
! src/utils/hsdis/binutils/hsdis-binutils.c

Changeset: 8fce5275
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-11 05:27:08 +0000
URL:       https://git.openjdk.org/leyden/commit/8fce5275fc94ebc404a6a37f5ea0407140de63c1

8339810: Clean up the code in sun.tools.jar.Main to properly close resources and use ZipFile during extract

Reviewed-by: lancea

! src/jdk.jartool/share/classes/sun/tools/jar/Main.java

Changeset: ceef161e
Branch: premain
Author:    Joel Sikstr?m <joel.sikstrom at oracle.com>
Committer: Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-11 08:08:09 +0000
URL:       https://git.openjdk.org/leyden/commit/ceef161eea51578160b71b20826a9328f9a87a88

8339661: ZGC: Move some page resets and verification to callsites

Reviewed-by: stefank, eosterlund

! src/hotspot/share/gc/z/zForwarding.cpp
! src/hotspot/share/gc/z/zPage.cpp
! src/hotspot/share/gc/z/zPage.hpp
! src/hotspot/share/gc/z/zPageAllocator.cpp
! src/hotspot/share/gc/z/zRelocate.cpp
! test/hotspot/gtest/gc/z/test_zForwarding.cpp

Changeset: 0b3f2e64
Branch: premain
Author:    Casper Norrbin <casper.norrbin at oracle.com>
Committer: Johan Sj?len <jsjolen at openjdk.org>
Date:      2024-09-11 08:45:59 +0000
URL:       https://git.openjdk.org/leyden/commit/0b3f2e64e83b589115989f9d14a6c644bc3008aa

8339242: Fix overflow issues in AdlArena

Reviewed-by: jsjolen, kbarrett

! src/hotspot/share/adlc/adlArena.cpp
! src/hotspot/share/adlc/adlArena.hpp
! src/hotspot/share/memory/arena.cpp

Changeset: 59778885
Branch: premain
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-09-11 11:18:38 +0000
URL:       https://git.openjdk.org/leyden/commit/597788850042e7272a23714c05ba546ee6080856

8339686: java/foreign/TestMappedHandshake.java fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames
8339780: TestByteBuffer fails on AIX after 8339285

Reviewed-by: alanb, jvernee

! src/java.base/share/classes/java/nio/Buffer.java
! src/java.base/share/classes/java/nio/MappedByteBuffer.java
! src/java.base/share/classes/java/nio/MappedMemoryUtils.java
! src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java
+ src/java.base/share/classes/jdk/internal/access/foreign/MappedMemoryUtilsProxy.java
! src/java.base/share/classes/jdk/internal/foreign/MappedMemorySegmentImpl.java
! src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template

Changeset: 55a7cf14
Branch: premain
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2024-09-11 13:51:31 +0000
URL:       https://git.openjdk.org/leyden/commit/55a7cf14453b6cd1de91362927b2fa63cba400a1

8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected

Reviewed-by: stuefe, asmehra

! src/hotspot/os/linux/cgroupSubsystem_linux.cpp
! src/hotspot/os/linux/cgroupSubsystem_linux.hpp
! src/hotspot/os/linux/cgroupUtil_linux.cpp
! src/hotspot/os/linux/cgroupUtil_linux.hpp
! src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp
! src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp
! src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp
! src/hotspot/os/linux/cgroupV2Subsystem_linux.hpp
! test/hotspot/gtest/runtime/test_cgroupSubsystem_linux.cpp

Changeset: bfe7f920
Branch: premain
Author:    Robbin Ehn <rehn at openjdk.org>
Date:      2024-09-11 16:08:24 +0000
URL:       https://git.openjdk.org/leyden/commit/bfe7f9205b56483b4364130a3a87c58c3fc82998

8339741: RISC-V: C ABI breakage for integer on stack

Reviewed-by: fyang, luhenry

! src/hotspot/cpu/riscv/interpreterRT_riscv.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
+ test/hotspot/jtreg/compiler/calls/TestManyArgs.java
+ test/hotspot/jtreg/compiler/calls/libTestManyArgs.c

Changeset: d9fdf69c
Branch: premain
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2024-09-11 16:57:13 +0000
URL:       https://git.openjdk.org/leyden/commit/d9fdf69c34c20e0f2d526c2f04450acb904c3e80

8333446: Add tests for hierarchical container support

Reviewed-by: mbaesken, zzambers

! src/hotspot/share/prims/whitebox.cpp
! test/hotspot/jtreg/TEST.ROOT
+ test/hotspot/jtreg/containers/systemd/HelloSystemd.java
+ test/hotspot/jtreg/containers/systemd/SystemdMemoryAwarenessTest.java
! test/jdk/TEST.ROOT
! test/jtreg-ext/requires/VMProps.java
+ test/lib/jdk/test/lib/containers/systemd/SystemdRunOptions.java
+ test/lib/jdk/test/lib/containers/systemd/SystemdTestUtils.java
! test/lib/jdk/test/whitebox/WhiteBox.java

Changeset: 51b85a1f
Branch: premain
Author:    Brent Christian <bchristi at openjdk.org>
Date:      2024-09-11 19:02:05 +0000
URL:       https://git.openjdk.org/leyden/commit/51b85a1f692fed7a66bdc0fae21438a60aafe7c2

8339687: Rearrange reachabilityFence()s in jdk.test.lib.util.ForceGC

Reviewed-by: dholmes, smarks, kbarrett

! test/lib/jdk/test/lib/util/ForceGC.java

Changeset: 35a94b76
Branch: premain
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-09-11 19:27:00 +0000
URL:       https://git.openjdk.org/leyden/commit/35a94b769761bd923fe6db03be672f05c1a74c38

8339803: Acknowledge case insensitive unambiguous keywords in tzdata files

Reviewed-by: jlu, coffeys

! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java
! make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java
! test/jdk/sun/util/calendar/zi/RuleRec.java
! test/jdk/sun/util/calendar/zi/Zoneinfo.java

Changeset: 237a540f
Branch: premain
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-09-11 19:40:02 +0000
URL:       https://git.openjdk.org/leyden/commit/237a540f0161cb6c8e922e28482e9e35bc4aa81b

8339801: Add better test failure diagnostics to vmTestbase/nsk/jdi/EventRequestManager/threadStartRequests/thrstartreq002

Reviewed-by: lmesnik, amenkov, kevinw

! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/threadStartRequests/thrstartreq002.java

Changeset: 591aa7c5
Branch: premain
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
Date:      2024-09-11 19:41:43 +0000
URL:       https://git.openjdk.org/leyden/commit/591aa7c5c7ebe2a289ed25f0b26126e30fba23f3

8335362: [Windows] Stack pointer increment in _cont_thaw stub can cause program to terminate with exit code 0xc0000005

Reviewed-by: dholmes, fparain

! src/hotspot/os/windows/os_windows.inline.hpp
! src/hotspot/share/runtime/continuationFreezeThaw.cpp
! src/hotspot/share/runtime/stackOverflow.hpp
+ test/jdk/java/lang/Thread/virtual/BigStackChunk.java

Changeset: b0cff6b5
Branch: premain
Author:    Viktor Klang <vklang at openjdk.org>
Date:      2024-09-11 20:02:49 +0000
URL:       https://git.openjdk.org/leyden/commit/b0cff6b528af7a2de453dd05d1c9ecbe7e00dc20

8299419: Thread.sleep(millis) may throw OOME

Reviewed-by: alanb

! src/java.base/share/classes/java/lang/Thread.java
! src/java.base/share/classes/jdk/internal/event/ThreadSleepEvent.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadController.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/SleepingThread.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/thread/strace001.java

Changeset: c3711dc9
Branch: premain
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-09-11 22:06:23 +0000
URL:       https://git.openjdk.org/leyden/commit/c3711dc90980fb3e63ff199612c201c4464626bf

8339678: Update runtime/condy tests to be executed with VM flags

Reviewed-by: coleenp

! test/hotspot/jtreg/ProblemList-Xcomp.txt
! test/hotspot/jtreg/runtime/condy/BadBSMUseTest.java
! test/hotspot/jtreg/runtime/condy/CondyLDCTest.java
! test/hotspot/jtreg/runtime/condy/CondyNewInvokeSpecialTest.java
! test/hotspot/jtreg/runtime/condy/escapeAnalysis/TestEscapeCondy.java
! test/hotspot/jtreg/runtime/condy/staticInit/TestInitException.java

Changeset: 1d392492
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-12 02:02:14 +0000
URL:       https://git.openjdk.org/leyden/commit/1d392492311daceeae12769cb9494eae63289853

8339834: Replace usages of -mx and -ms in some tests

Reviewed-by: aivanov, ascarpino, prr, dholmes

! src/java.base/share/classes/sun/security/util/Cache.java
! test/hotspot/jtreg/resourcehogs/compiler/intrinsics/string/TestStringIntrinsics2LargeArray.java
! test/jdk/java/beans/Introspector/8159696/UnloadClassBeanInfo.java
! test/jdk/java/beans/Introspector/Test5102804.java
! test/jdk/java/beans/Introspector/Test8027905.java
! test/jdk/java/beans/XMLEncoder/Test4646747.java
! test/jdk/java/lang/ref/SoftReference/Pin.java
! test/jdk/java/nio/Buffer/Chew.java
! test/jdk/tools/jimage/JImageToolTest.java

Changeset: 6d4bd6c6
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-12 02:06:09 +0000
URL:       https://git.openjdk.org/leyden/commit/6d4bd6c6b6c3e6ef4c0a1e4eebf888156e43da58

8339835: Replace usages of -mx and -ms in some client-libs tests

Reviewed-by: azvegint, prr

! test/jdk/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java
! test/jdk/javax/print/PrintServiceLookup/FlushCustomClassLoader.java
! test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java
! test/jdk/javax/swing/JFileChooser/6396844/TwentyThousandTest.java
! test/jdk/javax/swing/JOptionPane/6464022/bug6464022.java
! test/jdk/javax/swing/UIDefaults/6795356/bug6795356.java
! test/jdk/javax/swing/border/TestTitledBorderLeak.java
! test/jdk/javax/swing/regtesthelpers/Util.java
! test/jdk/sun/java2d/Disposer/TestDisposerLeak.java
! test/jdk/sun/java2d/Disposer/TestDisposerRace.java
! test/jdk/sun/java2d/marlin/CrashTest.java

Changeset: cfbf74fc
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-09-12 06:14:06 +0000
URL:       https://git.openjdk.org/leyden/commit/cfbf74fca493515495212d48a12ed109785eccc4

8339159: api/java_rmi/Naming/Rebind.html crashes with SEGV from UTF8::quoted_ascii_length call

Reviewed-by: iklam, aboldtch

! src/hotspot/share/classfile/symbolTable.cpp

Changeset: ac3f92b4
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-09-12 07:06:53 +0000
URL:       https://git.openjdk.org/leyden/commit/ac3f92b4110b05906a49c4146774fd6324c6d198

8339731: java.desktop/share/classes/javax/swing/text/html/default.css typo in margin settings

Reviewed-by: prr

! src/java.desktop/share/classes/javax/swing/text/html/default.css

Changeset: 315abdf8
Branch: premain
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2024-09-12 07:19:54 +0000
URL:       https://git.openjdk.org/leyden/commit/315abdf8c835e95d9c509f72b7ae21e6b59e4a29

8339733: C2: some nodes can have incorrect control after do_range_check()

Reviewed-by: chagedorn, thartmann

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

Changeset: 3c40afa5
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-09-12 08:31:18 +0000
URL:       https://git.openjdk.org/leyden/commit/3c40afa59c93860150960d478a9d2ffe33d4ce32

8334165: Remove serialVersionUID compatibility logic from JMX

Reviewed-by: dfuchs

! src/java.management/share/classes/javax/management/ClassAttributeValueExp.java
! src/java.management/share/classes/javax/management/MBeanAttributeInfo.java
! src/java.management/share/classes/javax/management/Notification.java
! src/java.management/share/classes/javax/management/NumericValueExp.java
! src/java.management/share/classes/javax/management/ObjectName.java
! src/java.management/share/classes/javax/management/modelmbean/DescriptorSupport.java
! src/java.management/share/classes/javax/management/modelmbean/InvalidTargetObjectTypeException.java
! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java
! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanConstructorInfo.java
! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanInfoSupport.java
! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanNotificationInfo.java
! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanOperationInfo.java
! src/java.management/share/classes/javax/management/modelmbean/XMLParseException.java
! src/java.management/share/classes/javax/management/relation/MBeanServerNotificationFilter.java
! src/java.management/share/classes/javax/management/relation/RelationNotification.java
! src/java.management/share/classes/javax/management/relation/RelationTypeSupport.java
! src/java.management/share/classes/javax/management/relation/Role.java
! src/java.management/share/classes/javax/management/relation/RoleInfo.java
! src/java.management/share/classes/javax/management/relation/RoleResult.java
! src/java.management/share/classes/javax/management/relation/RoleUnresolved.java
+ test/jdk/javax/management/ObjectName/SerialCompatRemovedTest.java
- test/jdk/javax/management/ObjectName/SerialCompatTest.java

Changeset: 1b17e0b1
Branch: premain
Author:    Alan Bateman <alanb at openjdk.org>
Date:      2024-09-12 08:48:17 +0000
URL:       https://git.openjdk.org/leyden/commit/1b17e0b133cab44029333c832bd046b338ede581

8338747: hasIncubatorModules needs to be generated when module resolution required at startup

Reviewed-by: iklam, ccheung

! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java

Changeset: 0765917d
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-12 15:08:11 +0000
URL:       https://git.openjdk.org/leyden/commit/0765917dea9376586697012b60605099750d8d42

8340011: Simplify jdk.internal.classfile.impl.EntryMap

Reviewed-by: liach

! src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java
! src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java

Changeset: 4d65c3ef
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-12 15:16:38 +0000
URL:       https://git.openjdk.org/leyden/commit/4d65c3efcaa5f855f9e0fbdd8e9d4f4ed2b44d3b

8339876: Move constant symbol caches to Utf8EntryImpl

Reviewed-by: redestad

! src/java.base/share/classes/java/lang/classfile/Annotation.java
! src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
! src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
! src/java.base/share/classes/java/lang/classfile/FieldModel.java
! src/java.base/share/classes/java/lang/classfile/MethodModel.java
! src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableInfo.java
! src/java.base/share/classes/java/lang/classfile/attribute/RecordComponentInfo.java
! src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java
! src/java.base/share/classes/java/lang/classfile/instruction/LocalVariable.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BoundLocalVariable.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedClassBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectClassBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectMethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/MethodImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java
! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java

Changeset: 7f1dae12
Branch: premain
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Date:      2024-09-12 15:24:22 +0000
URL:       https://git.openjdk.org/leyden/commit/7f1dae12e5e24d204a70cf610a8c482996556931

8339874: Avoid duplicate checking of trailing slash in ZipFile.getZipEntry

Reviewed-by: lancea, redestad

! src/java.base/share/classes/java/util/zip/ZipCoder.java
! src/java.base/share/classes/java/util/zip/ZipFile.java

Changeset: ab9b72c5
Branch: premain
Author:    Steve Dohrmann <sdohrmann at openjdk.org>
Date:      2024-09-12 16:06:16 +0000
URL:       https://git.openjdk.org/leyden/commit/ab9b72c50a5f324e53b8c6535f401cc185b98c75

8329035: New Data Destination instructions support

Reviewed-by: kvn, sviswanathan, jbhateja

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp

Changeset: 81ff91ef
Branch: premain
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-09-12 18:31:08 +0000
URL:       https://git.openjdk.org/leyden/commit/81ff91ef27a6a856ae2c453a9a9b8333b91da3ab

8339531: Improve performance of MemorySegment::mismatch

Reviewed-by: mcimadamore

! src/java.base/share/classes/java/lang/foreign/MemorySegment.java
! src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
+ src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java
! test/jdk/java/foreign/TestMismatch.java
- test/micro/org/openjdk/bench/java/lang/foreign/CopyTest.java
+ test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkCopy.java
+ test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkFill.java
+ test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkMismatch.java
- test/micro/org/openjdk/bench/java/lang/foreign/TestFill.java

Changeset: 5e5942a2
Branch: premain
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
Date:      2024-09-12 23:05:15 +0000
URL:       https://git.openjdk.org/leyden/commit/5e5942a282e14846404b68c65d43594d6b9226d9

8339794: Open source closed choice tests #1

Reviewed-by: jdv, prr

+ test/jdk/java/awt/Choice/ChoiceInsertTest.java
+ test/jdk/java/awt/Choice/ChoiceMouseDragTest.java
+ test/jdk/java/awt/Choice/WheelEventsConsumed.java

Changeset: ae75ca05
Branch: premain
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-13 05:47:44 +0000
URL:       https://git.openjdk.org/leyden/commit/ae75ca05e450da577e712eb7ed9dd9203616b80b

8314842: zgc/genzgc tests ignore vm flags

Reviewed-by: tschatzl, lmesnik

! test/hotspot/jtreg/gc/x/TestAllocateHeapAt.java
! test/hotspot/jtreg/gc/x/TestPageCacheFlush.java
! test/hotspot/jtreg/gc/x/TestSmallHeap.java
! test/hotspot/jtreg/gc/z/TestAllocateHeapAt.java
! test/hotspot/jtreg/gc/z/TestPageCacheFlush.java
! test/hotspot/jtreg/gc/z/TestSmallHeap.java

Changeset: b88ff9c9
Branch: premain
Author:    Andrew Dinn <adinn at openjdk.org>
Date:      2024-09-13 06:43:38 +0000
URL:       https://git.openjdk.org/leyden/commit/b88ff9c986bfe5e14e2ba5803a464fbf6e131df8

8339849: Enumerate opto and C1 stubs, generate enums, names, fields and generator calls

Reviewed-by: kvn

! src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp
! 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_Runtime1_aarch64.cpp
! src/hotspot/cpu/arm/c1_CodeStubs_arm.cpp
! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp
! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp
! src/hotspot/cpu/arm/c1_Runtime1_arm.cpp
! src/hotspot/cpu/ppc/c1_CodeStubs_ppc.cpp
! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp
! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp
! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/c1_Runtime1_ppc.cpp
! src/hotspot/cpu/riscv/c1_CodeStubs_riscv.cpp
! src/hotspot/cpu/riscv/c1_LIRAssembler_arraycopy_riscv.cpp
! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp
! src/hotspot/cpu/riscv/c1_LIRGenerator_riscv.cpp
! src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/c1_Runtime1_riscv.cpp
! src/hotspot/cpu/s390/c1_CodeStubs_s390.cpp
! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp
! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp
! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
! src/hotspot/cpu/s390/c1_Runtime1_s390.cpp
! src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp
! 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_Runtime1_x86.cpp
! src/hotspot/share/c1/c1_CodeStubs.hpp
! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/c1/c1_Runtime1.hpp
! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp
! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp
! src/hotspot/share/gc/x/c1/xBarrierSetC1.cpp
! src/hotspot/share/gc/z/c1/zBarrierSetC1.cpp
! src/hotspot/share/opto/escape.cpp
! src/hotspot/share/opto/runtime.cpp
! src/hotspot/share/opto/runtime.hpp
! src/hotspot/share/runtime/stubDeclarations.hpp
! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java
! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java

Changeset: cc1d328d
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-09-25 22:52:05 +0000
URL:       https://git.openjdk.org/leyden/commit/cc1d328d337c19c64becc0036bd52021dd43bc61

Merge branch 'master' into premain

! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/c1/c1_Runtime1.hpp
! src/hotspot/share/classfile/symbolTable.cpp
! src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp
! src/hotspot/share/memory/allocation.cpp
! src/hotspot/share/memory/metaspace.cpp
! src/hotspot/share/oops/array.inline.hpp
! src/hotspot/share/oops/cpCache.hpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/oops/klass.hpp
! src/hotspot/share/opto/runtime.cpp
! src/hotspot/share/opto/runtime.hpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/sharedRuntime.hpp
+ src/hotspot/share/runtime/stubDeclarations.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/TEST.ROOT
! test/hotspot/jtreg/runtime/cds/appcds/StaticArchiveWithLambda.java
! test/jtreg-ext/requires/VMProps.java
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/c1/c1_Runtime1.hpp
! src/hotspot/share/classfile/symbolTable.cpp
+ src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp
! src/hotspot/share/memory/allocation.cpp
! src/hotspot/share/memory/metaspace.cpp
! src/hotspot/share/oops/array.inline.hpp
! src/hotspot/share/oops/cpCache.hpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/oops/klass.hpp
! src/hotspot/share/opto/runtime.cpp
! src/hotspot/share/opto/runtime.hpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/sharedRuntime.hpp
! src/hotspot/share/runtime/stubDeclarations.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/TEST.ROOT
! test/hotspot/jtreg/runtime/cds/appcds/StaticArchiveWithLambda.java
! test/jtreg-ext/requires/VMProps.java

Changeset: ce1b43aa
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-09-26 00:25:10 +0000
URL:       https://git.openjdk.org/leyden/commit/ce1b43aaff14e028172a1349bd7e801222c0e7c9

Need to clean up _orig_to_scratch_object_table when classes are unloaded (e.g., when jdk.internal.event.Event gets rewritten by JFR)

! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/oops/instanceKlass.cpp

Changeset: 5709c379
Branch: premain
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-09-13 06:48:44 +0000
URL:       https://git.openjdk.org/leyden/commit/5709c379408d8919b86bbad6635b97756461ab27

8340081: Test java/foreign/TestLinker.java failed failed: missing permission java.lang.foreign.native.threshold.power.fill

Reviewed-by: dholmes

! src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java

Changeset: bacd0460
Branch: premain
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-09-13 08:05:19 +0000
URL:       https://git.openjdk.org/leyden/commit/bacd046062bffb4c95ec7a508a1080ad651a94a4

8321010: RISC-V: C2 RoundVF
8321011: RISC-V: C2 RoundVD

Reviewed-by: rehn, luhenry

! src/hotspot/cpu/riscv/assembler_riscv.hpp
! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.hpp
! src/hotspot/cpu/riscv/riscv.ad
! src/hotspot/cpu/riscv/riscv_v.ad
+ test/hotspot/jtreg/compiler/floatingpoint/TestRoundFloatAll.java
+ test/hotspot/jtreg/compiler/lib/golden/GoldenRound.java
+ test/hotspot/jtreg/compiler/vectorization/TestRoundVectRiscv64.java
+ test/hotspot/jtreg/compiler/vectorization/TestRoundVectorDoubleRandom.java
+ test/hotspot/jtreg/compiler/vectorization/TestRoundVectorFloatAll.java
+ test/hotspot/jtreg/compiler/vectorization/TestRoundVectorFloatRandom.java

Changeset: 0c36177f
Branch: premain
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-09-13 08:43:38 +0000
URL:       https://git.openjdk.org/leyden/commit/0c36177fead8b64a4cee9da3c895e3799f8ba231

8340089: Simplify SegmentBulkOperations::powerOfProperty

Reviewed-by: jpai

! src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java

Changeset: 358ff196
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-13 11:22:39 +0000
URL:       https://git.openjdk.org/leyden/commit/358ff196336407484b1b892f08936e9378701959

8339727: Open source several AWT focus tests - series 1

Reviewed-by: honkar

! test/jdk/ProblemList.txt
+ test/jdk/java/awt/Focus/ActivateOnProperAppContextTest.java
+ test/jdk/java/awt/Focus/KillFocusTest.java
+ test/jdk/java/awt/Focus/TestDisabledAutoTransfer.java
+ test/jdk/java/awt/Focus/TestDisabledAutoTransferSwing.java

Changeset: 8a4ea09f
Branch: premain
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-09-13 12:04:31 +0000
URL:       https://git.openjdk.org/leyden/commit/8a4ea09fa220f74f2236fc85e197eadf83b65875

8336492: Regression in lambda serialization

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+ src/jdk.compiler/share/classes/com/sun/tools/javac/comp/CaptureScanner.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeScanner.java
! test/jdk/jdk/internal/vm/Continuation/Scoped.java
! test/langtools/tools/javac/MethodParameters/LambdaTest.out
! test/langtools/tools/javac/MethodParameters/LocalClassTest.out
! test/langtools/tools/javac/T8019486/WrongLNTForLambdaTest.java
! test/langtools/tools/javac/classfiles/attributes/EnclosingMethod/EnclosingMethodTest.java
+ test/langtools/tools/javac/lambda/CaptureVarOrder.java
+ test/langtools/tools/javac/lambda/SerializedLambdaInLocalClass.java

Changeset: bd44cf8a
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-09-13 12:10:11 +0000
URL:       https://git.openjdk.org/leyden/commit/bd44cf8ab709d08a4d015868bececabd0c97525b

8330302: strace004 can still fail

Reviewed-by: alanb, shade

! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadController.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/SleepingThread.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/thread/strace001.java

Changeset: 4d011785
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-09-13 13:05:37 +0000
URL:       https://git.openjdk.org/leyden/commit/4d011785717c34fa5a245735968c60142fc14af4

8339927: Man page update for deprecating jhsdb debugd for removal

Reviewed-by: sspitsyn, cjplummer

! src/jdk.hotspot.agent/share/man/jhsdb.1

Changeset: 3c4d15bd
Branch: premain
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2024-09-13 14:13:47 +0000
URL:       https://git.openjdk.org/leyden/commit/3c4d15bdceaf94698af99d6b6fb12b3a28e13fdf

8334301: Errors in jpackage man page

Reviewed-by: almatvee

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

Changeset: 3e0da58e
Branch: premain
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-09-13 14:38:24 +0000
URL:       https://git.openjdk.org/leyden/commit/3e0da58ee6553fc0ed841db4a8800d50bc444517

8333843: Provide guidelines on MemorySegment to read strings with known lengths

Reviewed-by: mcimadamore

! src/java.base/share/classes/java/lang/foreign/MemorySegment.java

Changeset: 89ca89cb
Branch: premain
Author:    Calvin Cheung <ccheung at openjdk.org>
Date:      2024-09-13 14:59:35 +0000
URL:       https://git.openjdk.org/leyden/commit/89ca89cb26270a405226415c296dc45d3535e74d

8338626: ClassLoaderExt::process_jar_manifest() should allow / separator on Windows

Reviewed-by: iklam, dholmes, matsaave

! src/hotspot/share/classfile/classLoaderExt.cpp
! test/hotspot/jtreg/runtime/cds/appcds/ClassPathAttr.java

Changeset: 1a0a5388
Branch: premain
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-09-13 15:27:50 +0000
URL:       https://git.openjdk.org/leyden/commit/1a0a53883f7c6f523b5fefb722e137258d527362

8340120: Remove redundant code in SegmentBulkOperations::mismatch

Reviewed-by: mcimadamore

! src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java

Changeset: 89c172ac
Branch: premain
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-09-13 16:49:28 +0000
URL:       https://git.openjdk.org/leyden/commit/89c172ac47a9cc238739338417015bf912ad5424

8340082: Use inline return tag in java.base

Reviewed-by: iris, prappo, lancea, djelinski, naoto, liach

! src/java.base/share/classes/java/io/ObjectInputFilter.java
! src/java.base/share/classes/java/io/ObjectInputStream.java
! src/java.base/share/classes/java/lang/annotation/Retention.java
! src/java.base/share/classes/java/nio/charset/MalformedInputException.java
! src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java
! src/java.base/share/classes/java/time/format/TextStyle.java
! src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicBoolean.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicInteger.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLong.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLongArray.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReference.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java
! src/java.base/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java
! src/java.base/share/classes/java/util/concurrent/atomic/LongAccumulator.java
! src/java.base/share/classes/java/util/jar/Manifest.java
! src/java.base/share/classes/java/util/zip/Deflater.java
! src/java.base/share/classes/java/util/zip/Inflater.java
! src/java.base/share/classes/java/util/zip/ZipEntry.java
! src/java.base/share/classes/java/util/zip/ZipFile.java

Changeset: 37bf589e
Branch: premain
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-09-13 16:56:01 +0000
URL:       https://git.openjdk.org/leyden/commit/37bf589ec087c80851abb9d35910f09850cea9f6

8339847: Broken link to the dieharder distribution website in SplittableRandom

Reviewed-by: iris, liach

! src/java.base/share/classes/java/util/SplittableRandom.java

Changeset: 3aa8338f
Branch: premain
Author:    Erik Joelsson <erikj at openjdk.org>
Date:      2024-09-13 18:31:46 +0000
URL:       https://git.openjdk.org/leyden/commit/3aa8338f4e7d88967e77dfb0bace1c4b5add72f1

8340075: Autoconf bundle cannot run on read-only filesystem

Reviewed-by: mikael

! make/devkit/createAutoconfBundle.sh

Changeset: fdfe503d
Branch: premain
Author:    Valerie Peng <valeriep at openjdk.org>
Date:      2024-09-13 21:13:54 +0000
URL:       https://git.openjdk.org/leyden/commit/fdfe503d016086cf78b5a8c27dbe45f0261c68ab

8335288: SunPKCS11 initialization will call C_GetMechanismInfo on unsupported mechanisms

Reviewed-by: mbalao, weijun, hchao

! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java
+ test/jdk/sun/security/pkcs11/Provider/RequiredMechCheck.cfg
+ test/jdk/sun/security/pkcs11/Provider/RequiredMechCheck.java

Changeset: fa502ecd
Branch: premain
Author:    Manukumar V S <mvs at openjdk.org>
Date:      2024-09-14 05:08:57 +0000
URL:       https://git.openjdk.org/leyden/commit/fa502ecd2d1040ee2fe26d0ac5dd547379a0ade7

8339943: Frame not disposed in java/awt/dnd/DropActionChangeTest.java

Reviewed-by: prr, azvegint

! test/jdk/java/awt/dnd/DropActionChangeTest.java

Changeset: c91fa278
Branch: premain
Author:    Liang Mao <lmao at openjdk.org>
Date:      2024-09-14 05:36:47 +0000
URL:       https://git.openjdk.org/leyden/commit/c91fa278fe17ab204beef0fcef1ada6dd0bc37bb

8339725: Concurrent GC crashed due to GetMethodDeclaringClass

Reviewed-by: lmesnik, coleenp, eosterlund, stefank

! make/test/JtregNativeHotspot.gmk
! src/hotspot/share/prims/jvmtiEnv.cpp
! src/hotspot/share/prims/jvmtiEnvBase.cpp
+ test/hotspot/jtreg/serviceability/jvmti/GetMethodDeclaringClass/TestUnloadedClass.java
+ test/hotspot/jtreg/serviceability/jvmti/GetMethodDeclaringClass/libTestUnloadedClass.cpp

Changeset: a8f143c6
Branch: premain
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2024-09-14 22:50:50 +0000
URL:       https://git.openjdk.org/leyden/commit/a8f143c6abe7669c232cabda3a4e8df726de036e

8306679: com/sun/jdi/InterruptHangTest.java asserts with -Xcomp -Dmain.wrapper=Virtual options

Reviewed-by: lmesnik, cjplummer

! src/hotspot/share/runtime/continuationFreezeThaw.cpp
! test/jdk/ProblemList-Xcomp.txt

Changeset: a0794e0a
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-16 03:48:55 +0000
URL:       https://git.openjdk.org/leyden/commit/a0794e0a054c5e7ed051efa6362726cdd7598255

8339639: Opensource few AWT PopupMenu tests

Reviewed-by: azvegint, prr

! test/jdk/ProblemList.txt
+ test/jdk/java/awt/PopupMenu/PopupHangTest.java
+ test/jdk/java/awt/PopupMenu/PopupMenuVisuals.java

Changeset: 0e0f10f9
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-16 05:31:46 +0000
URL:       https://git.openjdk.org/leyden/commit/0e0f10f95217b5caaed02744a0a341350e4f2bc7

8340102: Move assert-only loop in OopMapSort::sort under debug macro

Reviewed-by: stuefe, fyang, kvn

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

Changeset: 74add0e2
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-16 05:32:03 +0000
URL:       https://git.openjdk.org/leyden/commit/74add0e2e071a8c8e9547e5a1757b5950b780539

8340105: Expose BitMap::print_on in release builds

Reviewed-by: stuefe, stefank

! src/hotspot/share/utilities/bitMap.cpp
! src/hotspot/share/utilities/bitMap.hpp

Changeset: dc00eb87
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-16 05:33:40 +0000
URL:       https://git.openjdk.org/leyden/commit/dc00eb87bc28ed5bf499af6835c3df474c454a41

8338912: CDS: Segmented roots array

Reviewed-by: ccheung, iklam

! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/archiveHeapLoader.cpp
! src/hotspot/share/cds/archiveHeapWriter.cpp
! src/hotspot/share/cds/archiveHeapWriter.hpp
! src/hotspot/share/cds/archiveUtils.cpp
! src/hotspot/share/cds/archiveUtils.hpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/filemap.hpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/heapShared.hpp

Changeset: 4b790637
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-16 05:41:58 +0000
URL:       https://git.openjdk.org/leyden/commit/4b7906375b4bd11a480665110561180825c2dd9c

8339842: Open source several AWT focus tests - series 2

Reviewed-by: prr

+ test/jdk/java/awt/Focus/FocusChangeOnResizeTest.java
+ test/jdk/java/awt/Focus/LightweightFocusLostTest.java
+ test/jdk/java/awt/Focus/MixedWeightFocus.java
+ test/jdk/java/awt/Focus/NextFocusHelperTest.java

Changeset: 6be15c3d
Branch: premain
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2024-09-16 08:15:48 +0000
URL:       https://git.openjdk.org/leyden/commit/6be15c3d0bf0bb3625f2ecd43d7aa10e81f6edd8

8340012: [C2] assert(KlassEncodingMetaspaceMax > pd) failed: change encoding max if new encoding after 8338526

Reviewed-by: kvn, coleenp

! src/hotspot/share/ci/ciKlass.hpp
! src/hotspot/share/oops/compressedKlass.inline.hpp
! src/hotspot/share/opto/compile.cpp

Changeset: a4eb9a06
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-16 08:34:54 +0000
URL:       https://git.openjdk.org/leyden/commit/a4eb9a063fb9e4a87923d464fe2c50ed5466acff

8339918: Remove checks for outdated -t -tm -Xfuture -checksource -cs -noasyncgc options from the launcher

Reviewed-by: dholmes, alanb

! src/java.base/share/classes/sun/launcher/resources/launcher.properties
! src/java.base/share/man/java.1
! src/java.base/share/native/libjli/java.c
! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java

Changeset: 54595188
Branch: premain
Author:    Johan Sj?len <jsjolen at openjdk.org>
Date:      2024-09-16 09:13:37 +0000
URL:       https://git.openjdk.org/leyden/commit/545951889c1ea68646be600decaf2bf4c049600b

8339627: Cleanup Unsafe.setMemory intrinsic code

Reviewed-by: tschatzl, fbredberg

! src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp
! src/hotspot/share/runtime/stubRoutines.hpp

Changeset: 05b9d479
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-16 14:06:02 +0000
URL:       https://git.openjdk.org/leyden/commit/05b9d47905a0dd6dd7a042f940fe120d3a8338d1

8340194: Replace usage of -ms with -Xms in LauncherCommon.gmk make file

Reviewed-by: ihse, jwaters

! make/common/modules/LauncherCommon.gmk

Changeset: e1ebeef0
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-16 14:08:08 +0000
URL:       https://git.openjdk.org/leyden/commit/e1ebeef0405ac6e48564a035767ee256291b9ca9

8340131: Refactor internal makeHiddenClassDefiner to take option mask instead of Set<ClassOption>

Reviewed-by: liach, jvernee

! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java

Changeset: 996790c7
Branch: premain
Author:    Volker Simonis <simonis at openjdk.org>
Date:      2024-09-16 14:55:53 +0000
URL:       https://git.openjdk.org/leyden/commit/996790c70f902d7840d0649a6b0867bed47c6537

8339954: Print JVMCI names with the Compiler.{perfmap,codelist,CodeHeap_Analytics} diagnostic commands

Reviewed-by: phh, dnsimon

! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/codeHeapState.cpp

Changeset: 1640bd26
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-16 16:22:38 +0000
URL:       https://git.openjdk.org/leyden/commit/1640bd2676d8d183f02b4f5386ce42c47950e356

8340186: Shenandoah: Missing load_reference_barrier_phantom_narrow match in is_shenandoah_lrb_call

Reviewed-by: kvn

! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp

Changeset: 65b9abaa
Branch: premain
Author:    Justin Lu <jlu at openjdk.org>
Date:      2024-09-16 17:26:47 +0000
URL:       https://git.openjdk.org/leyden/commit/65b9abaa29eb9fe801b650ce787d98c31770a5dc

8339769: Incorrect error message during startup if working directory does not exist

Reviewed-by: naoto, dholmes, alanb

! src/java.base/unix/native/libjava/java_props_md.c

Changeset: 89759c8b
Branch: premain
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2024-09-16 18:08:09 +0000
URL:       https://git.openjdk.org/leyden/commit/89759c8b02ec73de0d734d10b16382109c7a8b45

8321935: Define the term 'standard doclet'

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/StandardDoclet.java

Changeset: 59407faf
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-09-16 18:24:47 +0000
URL:       https://git.openjdk.org/leyden/commit/59407faf7b6861d142dbc3700a6fa9615567a275

8310525: DynamicLauncher for JDP test needs to try harder to find a free port

Reviewed-by: lmesnik, cjplummer

! test/jdk/sun/management/jdp/DynamicLauncher.java
! test/jdk/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java

Changeset: 858b4f12
Branch: premain
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
Committer: Y. Srinivas Ramakrishna <ysr at openjdk.org>
Date:      2024-09-16 19:15:30 +0000
URL:       https://git.openjdk.org/leyden/commit/858b4f127ad873666f51f4c54c37fa2d7801c32c

8339960: GenShen: Fix inconsistencies in generational Shenandoah behavior

Reviewed-by: wkemper, rkennke

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

Changeset: b26645f6
Branch: premain
Author:    Phil Race <prr at openjdk.org>
Date:      2024-09-16 19:28:20 +0000
URL:       https://git.openjdk.org/leyden/commit/b26645f64bb6dd3efafaceb92bedeaf8f93906e3

8339883: Open source several AWT/2D related tests

Reviewed-by: psadhukhan, honkar

+ test/jdk/java/awt/GraphicsConfiguration/NonDefaultGC.java
+ test/jdk/java/awt/GraphicsConfiguration/Position.java
+ test/jdk/sun/java2d/pipe/DrawImageBgTest.java
= test/jdk/sun/java2d/pipe/duke.gif

Changeset: 418bb42b
Branch: premain
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-09-16 20:03:00 +0000
URL:       https://git.openjdk.org/leyden/commit/418bb42b95b177f5f31f756054d0dd83740c6686

8340073: Support "%z" time zone abbreviation format in TZ files

Reviewed-by: jlu, joehw, coffeys

! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java
! src/java.base/share/classes/sun/util/cldr/CLDRTimeZoneNameProviderImpl.java

Changeset: 99d71850
Branch: premain
Author:    Denghui Dong <ddong at openjdk.org>
Date:      2024-09-17 00:13:47 +0000
URL:       https://git.openjdk.org/leyden/commit/99d7185071a5daa695adc6255d37ce382285a9b3

8340144: C1: remove unused Compilation::_max_spills

Reviewed-by: thartmann, shade

! src/hotspot/share/c1/c1_Compilation.cpp
! src/hotspot/share/c1/c1_Compilation.hpp

Changeset: 3e03e667
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-17 00:56:31 +0000
URL:       https://git.openjdk.org/leyden/commit/3e03e6673acfea543d0dbbc64b7a4f52e3292c2b

8340176: Replace usage of -noclassgc with -Xnoclassgc in test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java

Reviewed-by: kevinw, lmesnik

! test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java

Changeset: a4cf1918
Branch: premain
Author:    Jatin Bhateja <jbhateja at openjdk.org>
Date:      2024-09-17 01:41:53 +0000
URL:       https://git.openjdk.org/leyden/commit/a4cf1918c963cbe0b0eee6db580f0769c0cbdbcc

8339793: Fix incorrect APX feature enabling with -XX:-UseAPX

Reviewed-by: kvn, thartmann, sviswanathan

! src/hotspot/cpu/x86/vm_version_x86.cpp

Changeset: 7849f252
Branch: premain
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-09-17 05:22:59 +0000
URL:       https://git.openjdk.org/leyden/commit/7849f252937dc774a1935cc4c68f2a46649f180b

8340184: Bug in CompressedKlassPointers::is_in_encodable_range

Reviewed-by: coleenp, rkennke, jsjolen

! src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/share/ci/ciKlass.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdKlassQueue.cpp
! src/hotspot/share/oops/compressedKlass.cpp
! src/hotspot/share/oops/compressedKlass.hpp
! src/hotspot/share/oops/compressedKlass.inline.hpp
! src/hotspot/share/utilities/globalDefinitions.hpp
+ test/hotspot/gtest/oops/test_compressedKlass.cpp
+ test/hotspot/jtreg/gtest/CompressedKlassGtest.java

Changeset: 10050a72
Branch: premain
Author:    Kangcheng Xu <kxu at openjdk.org>
Date:      2024-09-17 07:19:02 +0000
URL:       https://git.openjdk.org/leyden/commit/10050a723954926926650af65417d5b828cba387

8332442: C2: refactor Mod cases in Compile::final_graph_reshaping_main_switch()

Reviewed-by: roland, chagedorn, jkarthikeyan

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/divnode.cpp
! src/hotspot/share/opto/divnode.hpp
! src/hotspot/share/opto/node.hpp
+ test/hotspot/jtreg/compiler/c2/TestDivModNodes.java
! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java

Changeset: 7834662c
Branch: premain
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2024-09-17 08:11:22 +0000
URL:       https://git.openjdk.org/leyden/commit/7834662ca35aeb202d177fde1044add611240ecd

8340119: Remove oopDesc::size_might_change()

Reviewed-by: stefank, iwalulya

! src/hotspot/share/oops/oop.cpp
! src/hotspot/share/oops/oop.hpp
! src/hotspot/share/oops/oop.inline.hpp

Changeset: c6721a0f
Branch: premain
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-17 09:18:54 +0000
URL:       https://git.openjdk.org/leyden/commit/c6721a0fa2582c3ddf1ef0a6e16a09234432939c

8340009: Improve the output from assert_different_registers

Reviewed-by: aboldtch, dholmes, shade, mli

! src/hotspot/share/asm/register.hpp
! src/hotspot/share/utilities/debug.hpp

Changeset: 8b6e2770
Branch: premain
Author:    Daniel Lund?n <dlunden at openjdk.org>
Date:      2024-09-17 09:53:55 +0000
URL:       https://git.openjdk.org/leyden/commit/8b6e2770a53002fcc9e07d38b954e6854a644f95

8340273: Remove CounterHalfLifeTime

Reviewed-by: chagedorn, dholmes

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

Changeset: 269cd38b
Branch: premain
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2024-09-17 10:39:31 +0000
URL:       https://git.openjdk.org/leyden/commit/269cd38b55391364db0f92291eb29c3b6803db94

8338566: Lazy creation of exception instances is not thread safe

Reviewed-by: shade, kvn, dlong

! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/ci/ciEnv.hpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/memory/universe.hpp
! src/hotspot/share/runtime/threads.cpp

Changeset: 80db6e71
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-09-17 11:58:58 +0000
URL:       https://git.openjdk.org/leyden/commit/80db6e71b092867212147bd369a9fda65dbd4b70

8339648: ZGC: Division by zero in rule_major_allocation_rate

Reviewed-by: aboldtch, lucy, tschatzl

! src/hotspot/share/gc/z/zDirector.cpp

Changeset: b39e6a84
Branch: premain
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-09-17 12:58:36 +0000
URL:       https://git.openjdk.org/leyden/commit/b39e6a84ef947661b5c878d02213da3a79bc026c

8329816: Add SLEEF version 3.6.1

Reviewed-by: erikj, mli, luhenry

! make/Main.gmk
+ make/UpdateSleefSource.gmk
! make/autoconf/basic_tools.m4
! make/autoconf/spec.gmk.template
+ src/jdk.incubator.vector/linux/legal/sleef.md
+ src/jdk.incubator.vector/linux/native/libsleef/README.md
+ src/jdk.incubator.vector/linux/native/libsleef/generated/misc.h
+ src/jdk.incubator.vector/linux/native/libsleef/generated/sleefinline_advsimd.h
+ src/jdk.incubator.vector/linux/native/libsleef/generated/sleefinline_rvvm1.h
+ src/jdk.incubator.vector/linux/native/libsleef/generated/sleefinline_sve.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/CHANGELOG.md
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/CMakeLists.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/CONTRIBUTORS.md
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/Configure.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/LICENSE.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/README.md
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/include/sleefdft.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/sleef-config.h.in
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/sleefConfig.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/CMakeLists.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperadvsimd.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperavx.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperavx2.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperavx2_128.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperavx512f.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperneon32.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperpower_128.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperpurec.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperpurec_scalar.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helperrvv.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helpers390x_128.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helpersse2.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helpersve.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/arch/helpervecext.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/CMakeLists.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/addSuffix.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/arraymap.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/arraymap.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/common.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/common.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/commonfuncs.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/dd.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/df.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/estrin.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/f128util.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/keywords.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/main_checkfeature.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/misc.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/common/quaddef.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft-tester/CMakeLists.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft-tester/bench1d.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft-tester/fftwtest1d.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft-tester/fftwtest2d.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft-tester/measuredft.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft-tester/naivetest.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft-tester/roundtriptest1d.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft-tester/roundtriptest2d.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft-tester/tutorial.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft/CMakeLists.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft/dft.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft/dftcommon.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft/dftcommon.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft/mkdispatch.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft/mkunroll.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft/unroll0.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/dft/vectortype.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/Makefile
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/dp.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/gencoef.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/gencoef.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/ld.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/mkrempitab.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/mkrempitabqp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/qp.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/simplexfr.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/gencoef/sp.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/Makefile
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/ProcessData.java
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/bench.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/benchsleef.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/benchsleef128.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/benchsleef256.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/benchsleef512.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/benchsvml.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/benchsvml128.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/benchsvml256.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/benchsvml512.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-benchmarks/measure.sh
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/CMakeLists.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/autovec.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/gnuabi_compatibility.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/hash_cinz.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/hash_finz.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/iut.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/iutcuda.cu
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/iutsimd.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/mveclibtest.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/tester.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/tester2dp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/tester2ld.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/tester2qp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/tester2simddp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/tester2simdsp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/tester2sp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/tester3.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/testerutil.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/testerutil.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm-tester/testervecabi.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/CMakeLists.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/dispatcher.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/dispavx.c.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/disppower_128.c.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/disps390x_128.c.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/dispscalar.c.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/dispscalar_footer.c.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/dispsse.c.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/funcproto.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/mkalias.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/mkdisp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/mkmasked_gnuabi.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/mkrename.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/mkrename_gnuabi.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/norename.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/rempitab.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/rename.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleef.pc.in
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleefdp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleefinline_cuda_header.h.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleefinline_header.h.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleefld.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleeflibm_footer.h.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleeflibm_header.h.org.in
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleefqp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleefsimddp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleefsimdsp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/sleefsp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/tryvsx3.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/libm/tryvxe2.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/CMakeLists.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/hash_printf.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/qiutcuda.cu
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/qiutsimd.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/qtester.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/qtesterutil.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/qtesterutil.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/qutil.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/tester2printf.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/tester2simdqp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad-tester/tester3printf.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/CMakeLists.txt
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/qdispatcher.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/qdispscalar.c.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/qdispx2.c.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/qfuncproto.h
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/qmkdisp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/qmkrename.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/rempitabqp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/sleefquad_footer.h.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/sleefquad_header.h.org.in
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/sleefquadinline_cuda_header.h.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/sleefquadinline_footer.h.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/sleefquadinline_header.h.org
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/src/quad/sleefsimdqp.c
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/aarch64-gcc.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/aarch64-llvm.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/armhf-gcc.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/armhf-llvm.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/native-gcc.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/native-llvm.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/ppc64el-gcc.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/ppc64el-llvm.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/riscv64-gcc.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/riscv64-llvm.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/s390x-gcc.cmake
+ src/jdk.incubator.vector/linux/native/libsleef/upstream/toolchains/s390x-llvm.cmake

Changeset: f8770163
Branch: premain
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-09-17 15:50:16 +0000
URL:       https://git.openjdk.org/leyden/commit/f87701635f82895fc10586e588f25e9c508e6979

8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win)

Reviewed-by: djelinski

! src/java.base/share/classes/java/nio/file/Path.java
! test/jdk/ProblemList.txt
! test/jdk/java/nio/file/Path/ToRealPath.java

Changeset: 64e3a9ee
Branch: premain
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-09-17 15:50:32 +0000
URL:       https://git.openjdk.org/leyden/commit/64e3a9ee91a6ae939e479a10cfc597e628c571e5

8339574: Behavior of File.is{Directory,File,Hidden} is not documented with respect to symlinks

Reviewed-by: djelinski, alanb

! src/java.base/share/classes/java/io/File.java
! src/java.base/share/classes/java/io/FileInputStream.java
! src/java.base/share/classes/java/io/FileOutputStream.java
! src/java.base/share/classes/java/io/RandomAccessFile.java

Changeset: 3e14fb9c
Branch: premain
Author:    David M. Lloyd <david.lloyd at redhat.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-09-17 16:24:38 +0000
URL:       https://git.openjdk.org/leyden/commit/3e14fb9c16e4ac3ad3c565059c534cfeacb45c7b

8340200: Misspelled constant `AttributesProcessingOption.DROP_UNSTABLE_ATRIBUTES`

Reviewed-by: liach

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

Changeset: 28d009ce
Branch: premain
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
Date:      2024-09-17 17:11:32 +0000
URL:       https://git.openjdk.org/leyden/commit/28d009ce0ecd4369351de859c491831b7f7bbb28

8339934: Simplify Math.scalb(double) method

Reviewed-by: darcy

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

Changeset: 90e92f98
Branch: premain
Author:    Jatin Bhateja <jbhateja at openjdk.org>
Date:      2024-09-17 17:46:36 +0000
URL:       https://git.openjdk.org/leyden/commit/90e92f98a6685b196b979853436668cf2b9f2117

8339790: Support Intel APX setzucc instruction

Reviewed-by: sviswanathan, jkarthikeyan, kvn

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/gc/x/x_x86_64.ad
! src/hotspot/cpu/x86/gc/z/z_x86_64.ad
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/x86_64.ad

Changeset: 5dc9723c
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-17 18:13:54 +0000
URL:       https://git.openjdk.org/leyden/commit/5dc9723c8172e288872f744bac5fd2342475767a

8340323: Test jdk/classfile/OptionsTest.java fails after JDK-8340200

Reviewed-by: alanb

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

Changeset: d5881825
Branch: premain
Author:    Calvin Cheung <ccheung at openjdk.org>
Date:      2024-09-17 18:58:46 +0000
URL:       https://git.openjdk.org/leyden/commit/d5881825ef442cac7076d551f0182f16b17b0b53

8338686: App classpath mismatch if a jar from the Class-Path attribute is on the classpath

Reviewed-by: dholmes, iklam

! src/hotspot/share/classfile/classLoader.cpp
! test/hotspot/jtreg/runtime/cds/appcds/ClassPathAttr.java

Changeset: eabfc6e4
Branch: premain
Author:    Gerard Ziemski <gziemski at openjdk.org>
Date:      2024-09-17 19:59:06 +0000
URL:       https://git.openjdk.org/leyden/commit/eabfc6e4d901c53b93a78da740ca376607d9576d

8337563: NMT: rename MEMFLAGS to MemTag

Reviewed-by: dholmes, coleenp, jsjolen

! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/gc/g1/g1BatchedTask.hpp
! src/hotspot/share/gc/g1/g1MonotonicArena.cpp
! src/hotspot/share/gc/g1/g1MonotonicArena.hpp
! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp
! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.hpp
! 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/serial/serialBlockOffsetTable.cpp
! src/hotspot/share/gc/shared/cardTable.cpp
! src/hotspot/share/gc/shared/oopStorage.cpp
! src/hotspot/share/gc/shared/oopStorage.hpp
! src/hotspot/share/gc/shared/oopStorage.inline.hpp
! src/hotspot/share/gc/shared/oopStorageSet.cpp
! src/hotspot/share/gc/shared/oopStorageSet.hpp
! src/hotspot/share/gc/shared/partialArrayState.cpp
! src/hotspot/share/gc/shared/stringdedup/stringDedupProcessor.cpp
! src/hotspot/share/gc/shared/taskqueue.hpp
! src/hotspot/share/gc/shared/taskqueue.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp
! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.inline.hpp
! src/hotspot/share/gc/x/xVirtualMemory.cpp
! src/hotspot/share/gc/z/zNMT.cpp
! src/hotspot/share/jfr/leakprofiler/chains/jfrbitset.hpp
! src/hotspot/share/jfr/metadata/metadata.xml
! src/hotspot/share/jfr/periodic/jfrNativeMemoryEvent.cpp
! src/hotspot/share/jfr/periodic/jfrNativeMemoryEvent.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp
! src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp
! src/hotspot/share/memory/allocation.cpp
! src/hotspot/share/memory/allocation.hpp
! src/hotspot/share/memory/allocation.inline.hpp
! src/hotspot/share/memory/arena.cpp
! src/hotspot/share/memory/arena.hpp
! src/hotspot/share/memory/guardedMemory.cpp
! src/hotspot/share/memory/heap.cpp
! src/hotspot/share/memory/memRegion.cpp
! src/hotspot/share/memory/memRegion.hpp
! src/hotspot/share/memory/metaspace.cpp
! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp
! src/hotspot/share/memory/padded.hpp
! src/hotspot/share/memory/padded.inline.hpp
! src/hotspot/share/memory/resourceArea.hpp
! src/hotspot/share/memory/virtualspace.cpp
! src/hotspot/share/nmt/allocationSite.hpp
! src/hotspot/share/nmt/arrayWithFreeList.hpp
! src/hotspot/share/nmt/mallocHeader.cpp
! src/hotspot/share/nmt/mallocHeader.hpp
! src/hotspot/share/nmt/mallocHeader.inline.hpp
! src/hotspot/share/nmt/mallocLimit.cpp
! src/hotspot/share/nmt/mallocLimit.hpp
! src/hotspot/share/nmt/mallocSiteTable.cpp
! src/hotspot/share/nmt/mallocSiteTable.hpp
! src/hotspot/share/nmt/mallocTracker.cpp
! src/hotspot/share/nmt/mallocTracker.hpp
! src/hotspot/share/nmt/mallocTracker.inline.hpp
! src/hotspot/share/nmt/memBaseline.cpp
! src/hotspot/share/nmt/memBaseline.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/memReporter.hpp
+ src/hotspot/share/nmt/memTag.hpp
+ src/hotspot/share/nmt/memTagBitmap.hpp
! src/hotspot/share/nmt/memTracker.cpp
! src/hotspot/share/nmt/memTracker.hpp
! src/hotspot/share/nmt/memTracker.inline.hpp
- src/hotspot/share/nmt/memflags.hpp
! src/hotspot/share/nmt/memoryFileTracker.cpp
! src/hotspot/share/nmt/memoryFileTracker.hpp
! src/hotspot/share/nmt/nativeCallStackPrinter.hpp
! src/hotspot/share/nmt/nmtCommon.cpp
! src/hotspot/share/nmt/nmtCommon.hpp
! src/hotspot/share/nmt/nmtPreInit.cpp
! src/hotspot/share/nmt/nmtPreInit.hpp
! src/hotspot/share/nmt/nmtUsage.cpp
! src/hotspot/share/nmt/nmtUsage.hpp
! src/hotspot/share/nmt/virtualMemoryTracker.cpp
! src/hotspot/share/nmt/virtualMemoryTracker.hpp
! src/hotspot/share/nmt/vmatree.cpp
! src/hotspot/share/nmt/vmatree.hpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvmtiAgentList.hpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/handles.hpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/lightweightSynchronizer.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! src/hotspot/share/runtime/safepointMechanism.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/services/threadService.cpp
! src/hotspot/share/utilities/bitMap.cpp
! src/hotspot/share/utilities/bitMap.hpp
! src/hotspot/share/utilities/chunkedList.hpp
! src/hotspot/share/utilities/concurrentHashTable.hpp
! src/hotspot/share/utilities/concurrentHashTable.inline.hpp
! src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp
! src/hotspot/share/utilities/debug.cpp
! src/hotspot/share/utilities/growableArray.cpp
! src/hotspot/share/utilities/growableArray.hpp
! src/hotspot/share/utilities/linkedlist.hpp
! src/hotspot/share/utilities/objectBitSet.hpp
! src/hotspot/share/utilities/objectBitSet.inline.hpp
! src/hotspot/share/utilities/resizeableResourceHash.hpp
! src/hotspot/share/utilities/resourceHash.hpp
! src/hotspot/share/utilities/stack.hpp
! src/hotspot/share/utilities/stack.inline.hpp
! test/hotspot/gtest/nmt/test_arrayWithFreeList.cpp
! test/hotspot/gtest/nmt/test_nmt_cornercases.cpp
! test/hotspot/gtest/nmt/test_nmt_malloclimit.cpp
! test/hotspot/gtest/nmt/test_nmt_reserved_region.cpp
! test/hotspot/gtest/nmt/test_nmt_totals.cpp
! test/hotspot/gtest/nmt/test_vmatree.cpp
! test/hotspot/gtest/utilities/test_growableArray.cpp
! test/hotspot/gtest/utilities/test_resourceHash.cpp
! test/hotspot/gtest/utilities/test_utf8.cpp

Changeset: f0ae90f3
Branch: premain
Author:    Harshitha Onkar <honkar at openjdk.org>
Date:      2024-09-17 20:05:46 +0000
URL:       https://git.openjdk.org/leyden/commit/f0ae90f30c346544e87217ef1832d6a350fe1985

8340210: Add positionTestUI() to PassFailJFrame.Builder

Co-authored-by: Alexey Ivanov <aivanov at openjdk.org>
Reviewed-by: aivanov, azvegint

! test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

Changeset: dfc90938
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-17 21:08:47 +0000
URL:       https://git.openjdk.org/leyden/commit/dfc90938ba36685ef58af0846ee4bdb214fa210f

8340132: Remove internal CpException for reading malformed utf8

Reviewed-by: asotona

! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java

Changeset: 202fd421
Branch: premain
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-09-17 22:36:37 +0000
URL:       https://git.openjdk.org/leyden/commit/202fd421f7e8b0f4a9c7393d1045e879acd13e64

8340213: jcmd VM.events ignores max argument

Reviewed-by: szaldana, cjplummer, amenkov, mli

! src/hotspot/share/services/diagnosticCommand.cpp
! test/hotspot/jtreg/serviceability/dcmd/vm/EventsTest.java

Changeset: 147e3007
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-18 04:33:28 +0000
URL:       https://git.openjdk.org/leyden/commit/147e30070d8adbe65453a3a9316b9324890ea25f

8340015: Open source several AWT focus tests - series 7

Reviewed-by: honkar

! test/jdk/ProblemList.txt
+ test/jdk/java/awt/Focus/MinimizeNonfocusableWindowTest.java
+ test/jdk/java/awt/Focus/WindowDisposeFocusTest.java
+ test/jdk/java/awt/Focus/bug6435715.java

Changeset: d23c59e4
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-18 07:01:13 +0000
URL:       https://git.openjdk.org/leyden/commit/d23c59e40812c9e3a5914193e68169dbdf6d09e5

8340280: Avoid calling MT.invokerType() when creating LambdaForms

Reviewed-by: liach, jvernee

! src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java
! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
! src/java.base/share/classes/java/lang/invoke/Invokers.java
! src/java.base/share/classes/java/lang/invoke/LambdaForm.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/java.base/share/classes/java/lang/invoke/NativeMethodHandle.java

Changeset: 5381f553
Branch: premain
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2024-09-18 07:07:45 +0000
URL:       https://git.openjdk.org/leyden/commit/5381f553ad61ddaa44d49c3039a05511cc68bdd0

8333258: C2: high memory usage in PhaseCFG::insert_anti_dependences()

Reviewed-by: kvn, epeter

! src/hotspot/share/opto/gcm.cpp
+ test/hotspot/jtreg/compiler/codegen/TestAntiDependenciesHighMemUsage.java
+ test/hotspot/jtreg/compiler/codegen/TestAntiDependenciesHighMemUsage2.java

Changeset: 3895b8fc
Branch: premain
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2024-09-18 08:26:33 +0000
URL:       https://git.openjdk.org/leyden/commit/3895b8fc0b2c6d187080dba6fe08297adad4a480

8340230: Tests crash: assert(is_in_encoding_range || k->is_interface() || k->is_abstract()) failed: sanity

Reviewed-by: thartmann, kvn

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

Changeset: 4ff17c14
Branch: premain
Author:    Simon Tooke <stooke at openjdk.org>
Date:      2024-09-18 09:11:40 +0000
URL:       https://git.openjdk.org/leyden/commit/4ff17c14a572a59b60d728c3626f430932eecea6

8319873: Add windows implementation for jcmd System.map and System.dump_map

Co-authored-by: Simon Tooke <stooke at openjdk.org>
Reviewed-by: stuefe, kevinw, szaldana

+ src/hotspot/os/windows/memMapPrinter_windows.cpp
! src/hotspot/share/nmt/memMapPrinter.cpp
! src/hotspot/share/nmt/memMapPrinter.hpp
! src/hotspot/share/services/diagnosticCommand.cpp
! src/hotspot/share/services/diagnosticCommand.hpp
! test/hotspot/jtreg/serviceability/dcmd/vm/SystemDumpMapTest.java
! test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java
! test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java
! test/jdk/sun/tools/jcmd/TestJcmdPIDSubstitution.java

Changeset: 45e438f3
Branch: premain
Author:    Nizar Benalla <nbenalla at openjdk.org>
Date:      2024-09-18 11:08:13 +0000
URL:       https://git.openjdk.org/leyden/commit/45e438f3f470c4af9d5066a4ae680f819bb3cde0

8339845: Update color.org and wapforum.org links to use HTTPS instead of HTTP

Reviewed-by: prr, honkar, aivanov

! src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java
! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java
! src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java
! src/java.desktop/share/classes/javax/imageio/package-info.java
! src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java

Changeset: 19b2cee4
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-09-18 11:44:14 +0000
URL:       https://git.openjdk.org/leyden/commit/19b2cee42081e1f8e9c53e6c831ce1d2d2915fd5

8340113: Remove JULONG as a Diagnostic Command argument type (jcmd JFR.view)

Reviewed-by: lmesnik, egahlin

! src/hotspot/share/jfr/recorder/service/jfrOptionSet.cpp
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/ArgumentParser.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/DCmdView.java

Changeset: aeba1ea7
Branch: premain
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-09-18 12:03:00 +0000
URL:       https://git.openjdk.org/leyden/commit/aeba1ea7c44d6b378decf8557c8cd9fc7bfb7df5

8340272: C2 SuperWord: JMH benchmark for Reduction vectorization

Reviewed-by: kvn, jkarthikeyan

+ test/micro/org/openjdk/bench/vm/compiler/VectorReduction2.java

Changeset: 1d070a32
Branch: premain
Author:    Rafael Winterhalter <winterhalter at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-09-18 12:33:56 +0000
URL:       https://git.openjdk.org/leyden/commit/1d070a3238a1cd8b9359357e6e3f751cd26a3f06

8337302: Undefined type variable results in null

Reviewed-by: liach

! src/java.base/share/classes/java/lang/TypeNotPresentException.java
! src/java.base/share/classes/sun/reflect/generics/factory/CoreReflectionFactory.java
+ test/jdk/java/lang/reflect/Generics/TestMissingTypeVariable.java

Changeset: 08a2f841
Branch: premain
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-09-18 12:37:02 +0000
URL:       https://git.openjdk.org/leyden/commit/08a2f841ec78a10f8d6d54b2ac3a92e89f765f14

8339738: RISC-V: Vectorize crc32 intrinsic

Reviewed-by: fyang, luhenry

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

Changeset: 471a51a5
Branch: premain
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-18 13:46:19 +0000
URL:       https://git.openjdk.org/leyden/commit/471a51a5a4395f0bc6818c3c1d30455ce75500d6

8340368: windows-x64-slowdebug build fails after JDK-8319873

Reviewed-by: jpai, kevinw, aboldtch, eosterlund

! src/hotspot/os/windows/memMapPrinter_windows.cpp

Changeset: ae39a660
Branch: premain
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-09-18 14:38:06 +0000
URL:       https://git.openjdk.org/leyden/commit/ae39a6603c6c33a36dce30c3290a634b08a6bf05

8339992: RISC-V: some minor improvements of base64_vector_decode_round

Reviewed-by: fyang, luhenry

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

Changeset: 6ff287ad
Branch: premain
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-09-18 15:57:41 +0000
URL:       https://git.openjdk.org/leyden/commit/6ff287ad9aa45d8a37aafb4dd7bd9170280f5bbb

8340233: Missed ThreadWXEnable in jfrNativeLibraryLoadEvent.cpp

Reviewed-by: mgronlun

! src/hotspot/share/jfr/support/jfrNativeLibraryLoadEvent.cpp

Changeset: 9cfc03aa
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-09-18 19:17:26 +0000
URL:       https://git.openjdk.org/leyden/commit/9cfc03aa81f2ae20616c8cc27e3467ad01cf985f

8340391: Windows jcmd System.map and System.dump_map tests failing

Reviewed-by: cjplummer

! test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java

Changeset: 31849127
Branch: premain
Author:    Harshitha Onkar <honkar at openjdk.org>
Date:      2024-09-18 19:25:11 +0000
URL:       https://git.openjdk.org/leyden/commit/31849127a06e448c705a61c536f51fc037bc4979

8339962: Open source AWT TextField tests - Set1

Reviewed-by: jdv, dnguyen, prr

+ test/jdk/java/awt/Label/ContainerValidateTest.java
+ test/jdk/java/awt/TextField/SetEchoCharTest.java
+ test/jdk/java/awt/TextField/SetEchoCharWordOpsTest.java

Changeset: 88a1c055
Branch: premain
Author:    Phil Race <prr at openjdk.org>
Date:      2024-09-18 20:39:40 +0000
URL:       https://git.openjdk.org/leyden/commit/88a1c0550e435888c571d32c577fd697652e5620

8340078: Open source several 2D tests

Reviewed-by: honkar

+ test/jdk/sun/java2d/GdiRendering/GdiBlitOffscreenTest.java
+ test/jdk/sun/java2d/GdiRendering/GdiLockTest.java
+ test/jdk/sun/java2d/SunGraphics2D/DrawRoundRect0Bug.java
+ test/jdk/sun/java2d/SunGraphics2D/RevalidateBug.java
+ test/jdk/sun/java2d/SunGraphics2D/ScaledPolyTest.java

Changeset: d9c67443
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-19 01:44:45 +0000
URL:       https://git.openjdk.org/leyden/commit/d9c67443f7d7f03efb2837b63ee2acc6113f737f

8340360: Update -mx to -Xmx in UnninstallUIMemoryLeaks test

Reviewed-by: serb, prr

! test/jdk/javax/swing/UI/UnninstallUIMemoryLeaks/UnninstallUIMemoryLeaks.java

Changeset: 537447f8
Branch: premain
Author:    Amit Kumar <amitkumar at openjdk.org>
Date:      2024-09-19 04:33:01 +0000
URL:       https://git.openjdk.org/leyden/commit/537447f8816129dad9a1edd21bd30f3edf69ea60

8339980: [s390x] ProblemList jdk/java/util/zip/CloseInflaterDeflaterTest.java

Reviewed-by: lucy

! test/jdk/ProblemList.txt

Changeset: ac58b610
Branch: premain
Author:    Amit Kumar <amitkumar at openjdk.org>
Date:      2024-09-19 04:47:15 +0000
URL:       https://git.openjdk.org/leyden/commit/ac58b6102a26ac2ca7f6df5f176d5b5ca1d00d45

8339416: [s390x] Provide implementation for resolve_global_jobject

Reviewed-by: mdoerr, lucy

! src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
! src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.hpp
! src/hotspot/cpu/s390/gc/shared/modRefBarrierSetAssembler_s390.cpp
! src/hotspot/cpu/s390/gc/shared/modRefBarrierSetAssembler_s390.hpp
! src/hotspot/cpu/s390/macroAssembler_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.hpp

Changeset: 67198992
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-19 06:28:05 +0000
URL:       https://git.openjdk.org/leyden/commit/67198992ce92da1ee615a73937f22fdaba28fba1

8286851: Deprecate for removal several of the undocumented java launcher options

Reviewed-by: dholmes

! src/java.base/share/native/libjli/java.c

Changeset: c58fbef0
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-09-19 08:28:51 +0000
URL:       https://git.openjdk.org/leyden/commit/c58fbef05eace85a2e429da1ac8ff1ae09a0b736

8340276: Test java/lang/management/ThreadMXBean/Locks.java failed with NullPointerException

Reviewed-by: cjplummer, lmesnik

! test/jdk/java/lang/management/ThreadMXBean/Locks.java

Changeset: 118c9ade
Branch: premain
Author:    Serhiy Sachkov <serhiy.sachkov at oracle.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-19 08:39:11 +0000
URL:       https://git.openjdk.org/leyden/commit/118c9ade1a5e17d870415f689caa25af6524ab0e

8338759: Add extra diagnostic to java/net/InetAddress/ptr/Lookup.java

Reviewed-by: dfuchs, shade

! test/jdk/java/net/InetAddress/ptr/Lookup.java

Changeset: 8908812d
Branch: premain
Author:    Joel Sikstr?m <joel.sikstrom at oracle.com>
Committer: Hamlin Li <mli at openjdk.org>
Date:      2024-09-19 08:47:20 +0000
URL:       https://git.openjdk.org/leyden/commit/8908812d0a64f25f0d033d44725a69348789b223

8337674: ZGC: Consistent style for naming private static constants

Reviewed-by: stefank, aboldtch, mli

! src/hotspot/cpu/aarch64/gc/z/zAddress_aarch64.cpp
! src/hotspot/cpu/ppc/gc/z/zAddress_ppc.cpp
! src/hotspot/cpu/riscv/gc/z/zAddress_riscv.cpp
! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.hpp
! src/hotspot/cpu/x86/gc/z/z_x86_64.ad
! src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp
! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
! src/hotspot/share/gc/z/zBarrierSet.hpp
! src/hotspot/share/gc/z/zDirector.cpp
! src/hotspot/share/gc/z/zDirector.hpp
! src/hotspot/share/gc/z/zLiveMap.cpp
! src/hotspot/share/gc/z/zLiveMap.hpp
! src/hotspot/share/gc/z/zLiveMap.inline.hpp
! src/hotspot/share/gc/z/zReferenceProcessor.hpp
! src/hotspot/share/gc/z/zStackWatermark.cpp
! src/hotspot/share/gc/z/zStackWatermark.hpp
! src/hotspot/share/gc/z/zStat.cpp
! src/hotspot/share/gc/z/zStat.hpp
! src/hotspot/share/gc/z/zStoreBarrierBuffer.cpp
! src/hotspot/share/gc/z/zStoreBarrierBuffer.hpp
! src/hotspot/share/gc/z/zValue.hpp
! src/hotspot/share/gc/z/zValue.inline.hpp
! src/hotspot/share/gc/z/zVerify.cpp

Changeset: 2faf8b8d
Branch: premain
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-09-19 09:44:57 +0000
URL:       https://git.openjdk.org/leyden/commit/2faf8b8d582183275b1fdc92313a1c63c1753e80

8340007: Refactor KeyEvent/FunctionKeyTest.java

Reviewed-by: azvegint

! test/jdk/java/awt/event/KeyEvent/FunctionKeyTest.java

Changeset: 0120d3ee
Branch: premain
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-09-19 11:48:45 +0000
URL:       https://git.openjdk.org/leyden/commit/0120d3eed50bdc9fa53f2c41b31791620aeef613

8340306: Add border around instructions in PassFailJFrame

Reviewed-by: honkar, prr

! test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

Changeset: cecb0b3d
Branch: premain
Author:    Serhiy Sachkov <serhiy.sachkov at oracle.com>
Committer: Michael McMahon <michaelm at openjdk.org>
Date:      2024-09-19 12:08:31 +0000
URL:       https://git.openjdk.org/leyden/commit/cecb0b3d11ed0ce204cb6c3427f5a6858a844aeb

8339787: Add some additional diagnostic output to java/net/ipv6tests/UdpTest.java

Reviewed-by: dfuchs

! test/jdk/java/net/ipv6tests/Tests.java

Changeset: 7579d374
Branch: premain
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2024-09-19 12:29:21 +0000
URL:       https://git.openjdk.org/leyden/commit/7579d3740217e4a819cbf63837ec929f00464585

8338995: New Object to ObjectMonitor mapping: PPC64 implementation

Reviewed-by: rrich, lucy

! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
! src/hotspot/share/runtime/basicLock.inline.hpp

Changeset: c9bee173
Branch: premain
Author:    Prasadrao Koppula <pkoppula at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
Date:      2024-09-19 13:21:08 +0000
URL:       https://git.openjdk.org/leyden/commit/c9bee173d61f4accfc4adc280ab5d21600191756

8331391: Enhance the keytool code by invoking the buildTrustedCerts method for essential options

Reviewed-by: coffeys, mullan

! src/java.base/share/classes/sun/security/tools/keytool/Main.java

Changeset: d555f072
Branch: premain
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-09-19 14:15:45 +0000
URL:       https://git.openjdk.org/leyden/commit/d555f072b2036664711242a242a35fb30d277e5a

8298614: Support CDS heap dumping for SerialGC and ParallelGC

Reviewed-by: dholmes, lmesnik, iklam

! src/hotspot/share/cds/archiveHeapWriter.cpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/heapShared.hpp
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/IncompatibleOptions.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsHumongous.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsUtils.java

Changeset: 3bb8de31
Branch: premain
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-09-19 14:18:03 +0000
URL:       https://git.openjdk.org/leyden/commit/3bb8de31457a544d9c20a12f8d8d30d6d1cd9cba

8338693: assert(Atomic::add(&ik->_shared_class_load_count, 1) == 1) failed: shared class loaded more than once

Reviewed-by: iklam, dholmes

! src/hotspot/share/classfile/systemDictionary.cpp

Changeset: 2ada313c
Branch: premain
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-09-19 15:25:04 +0000
URL:       https://git.openjdk.org/leyden/commit/2ada313cdd9a20ed33f7e0a7298c8a0e69a81c6f

8340329: (fs) Message of NotLinkException thrown by FIles.readSymbolicLink does not include file name (win)

Reviewed-by: alanb

! src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java
! test/jdk/java/nio/file/Files/Links.java

Changeset: 5f3e7aa8
Branch: premain
Author:    Justin Lu <jlu at openjdk.org>
Date:      2024-09-19 16:18:37 +0000
URL:       https://git.openjdk.org/leyden/commit/5f3e7aa83348edafb83480ce67d0c58c46e11b24

8339735: Remove references to Applet in core-libs/security APIs

Reviewed-by: coffeys, naoto, iris, rriggs, lancea, mullan

! src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html
! src/java.base/share/classes/java/net/HttpURLConnection.java
! src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java
! src/java.base/share/classes/javax/crypto/CryptoPermission.java
! src/java.base/share/classes/javax/crypto/ExemptionMechanism.java
! src/java.base/share/classes/javax/crypto/JceSecurityManager.java
! src/java.base/share/classes/javax/net/SocketFactory.java

Changeset: bc36ace7
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-19 16:22:17 +0000
URL:       https://git.openjdk.org/leyden/commit/bc36ace72c1189dcd6d0c05d40d8c568acd89b01

8340271: Open source several AWT Robot tests

Reviewed-by: abhiscxk, honkar

+ test/jdk/java/awt/Robot/CreateScreenCapture.java
+ test/jdk/java/awt/Robot/RobotScrollTest.java

Changeset: d1d82400
Branch: premain
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-09-19 16:59:51 +0000
URL:       https://git.openjdk.org/leyden/commit/d1d824008d1dc70029013820814fd03c40b4e309

8340308: PassFailJFrame: Make rows default to number of lines in instructions

Reviewed-by: honkar, azvegint

! test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

Changeset: ec3cba02
Branch: premain
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-09-19 17:10:23 +0000
URL:       https://git.openjdk.org/leyden/commit/ec3cba02963b5128480bcf62431ab03ecdb26db6

8340399: Update comment in SourceVersion for language evolution history

Reviewed-by: iris

! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java

Changeset: 15ae1155
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-19 17:47:08 +0000
URL:       https://git.openjdk.org/leyden/commit/15ae1155a11b401e3d1dd39177c209f17f077119

8340166: [REDO] CDS: Trim down minimum GC region alignment

Reviewed-by: ccheung, iklam

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

Changeset: 75d5e117
Branch: premain
Author:    William Kemper <wkemper at openjdk.org>
Date:      2024-09-19 17:55:23 +0000
URL:       https://git.openjdk.org/leyden/commit/75d5e117770590d2432fcfe8d89734c7038d4e55

8340400: Shenandoah: Whitebox breakpoint GC requests may cause assertions

Reviewed-by: shade

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

Changeset: fde85083
Branch: premain
Author:    Alexander Zuev <kizune at openjdk.org>
Date:      2024-09-19 19:51:05 +0000
URL:       https://git.openjdk.org/leyden/commit/fde8508379d2983fa70784faef60699c81f9c359

8339902: Open source couple TextField related tests

Reviewed-by: honkar

+ test/jdk/java/awt/TextField/CaretPositionTest/CaretPositionTest.java
+ test/jdk/java/awt/TextField/SetBoundsTest/SetBoundsTest.java
+ test/jdk/java/awt/TextField/SetEchoCharTest4/SetEchoCharTest4.java
+ test/jdk/java/awt/TextField/SetPasswordTest/SetPasswordTest.java
+ test/jdk/java/awt/TextField/ZeroEchoCharTest/ZeroEchoCharTest.java

Changeset: 296b4963
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-09-19 21:06:46 +0000
URL:       https://git.openjdk.org/leyden/commit/296b49634eed83bca6cfdee514b9c7c4f8252d59

8340353: Remove CompressedOops::ptrs_base

Reviewed-by: stefank, coleenp, shade, mli

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/share/oops/compressedOops.hpp

Changeset: fdc16a37
Branch: premain
Author:    Phil Race <prr at openjdk.org>
Date:      2024-09-19 22:20:05 +0000
URL:       https://git.openjdk.org/leyden/commit/fdc16a373459cb2311316448c765b1bee5c73694

8340480: Bad copyright notices in changes from JDK-8339902

Reviewed-by: kcr, bpb, kizune

! test/jdk/java/awt/TextField/CaretPositionTest/CaretPositionTest.java
! test/jdk/java/awt/TextField/SetBoundsTest/SetBoundsTest.java
! test/jdk/java/awt/TextField/SetEchoCharTest4/SetEchoCharTest4.java
! test/jdk/java/awt/TextField/SetPasswordTest/SetPasswordTest.java
! test/jdk/java/awt/TextField/ZeroEchoCharTest/ZeroEchoCharTest.java

Changeset: 969c2af9
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-09-19 23:45:26 +0000
URL:       https://git.openjdk.org/leyden/commit/969c2af95387992c55a2e1768de848a354e74127

8339192: Native annotation parsing code of deprecated annotations causes crash

Reviewed-by: jrose, mgronlun

! src/hotspot/share/classfile/classFileParser.cpp
+ test/hotspot/jtreg/runtime/Annotations/BadContendedGroupBadCPIndex.jcod
+ test/hotspot/jtreg/runtime/Annotations/BadContendedGroupWrongType.jcod
+ test/hotspot/jtreg/runtime/Annotations/BadDeprecatedExtraMemberAtEnd.jcod
+ test/hotspot/jtreg/runtime/Annotations/BadDeprecatedExtraMemberAtStart.jcod
+ test/hotspot/jtreg/runtime/Annotations/BadDeprecatedForRemovalBadCPIndex.jcod
+ test/hotspot/jtreg/runtime/Annotations/BadDeprecatedForRemovalWrongType.jcod
+ test/hotspot/jtreg/runtime/Annotations/BadDeprecatedSinceWrongType.jcod
+ test/hotspot/jtreg/runtime/Annotations/TestBadAnnotations.java

Changeset: 94c33179
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-20 03:05:22 +0000
URL:       https://git.openjdk.org/leyden/commit/94c33179b6a1205100d7c125f3a7c11e29621db9

8339895: Open source several AWT focus tests - series 3

Reviewed-by: prr

! test/jdk/ProblemList.txt
+ test/jdk/java/awt/Focus/ActivateFocusTest.java
+ test/jdk/java/awt/Focus/CanvasPanelFocusOnClickTest.java
+ test/jdk/java/awt/Focus/FocusPolicyTest.java
+ test/jdk/java/awt/Focus/RequestInInactiveFrame.java

Changeset: 0f7d9e59
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-09-20 04:15:55 +0000
URL:       https://git.openjdk.org/leyden/commit/0f7d9e599593bb8e31e7e33a559d25ec803c7ba4

8340436: Remove unused CompressedOops::AnyNarrowOopMode

Reviewed-by: haosun, dholmes

! src/hotspot/share/oops/compressedOops.hpp

Changeset: f4e40179
Branch: premain
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Date:      2024-09-20 04:19:12 +0000
URL:       https://git.openjdk.org/leyden/commit/f4e401791efb920b9773f2886b34904c95106727

8339984: Open source AWT MenuItem related tests

Reviewed-by: aivanov

+ test/jdk/java/awt/MenuItem/GiantFontTest.java
+ test/jdk/java/awt/MenuItem/LotsOfMenuItemsTest.java
+ test/jdk/java/awt/MenuItem/MenuSetFontTest.java
+ test/jdk/java/awt/MenuItem/NullOrEmptyStringLabelTest.java
+ test/jdk/java/awt/MenuItem/UnicodeMenuItemTest.java

Changeset: 46b02f49
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-20 06:06:27 +0000
URL:       https://git.openjdk.org/leyden/commit/46b02f49bcc730d94e37cf17fa996fdd12bdb990

8339906: Open source several AWT focus tests - series 4

Reviewed-by: abhiscxk, prr

+ test/jdk/java/awt/Focus/AltTabEventsTest.java
+ test/jdk/java/awt/Focus/ComponentLostFocusTest.java
+ test/jdk/java/awt/Focus/FocusKeepTest.java
+ test/jdk/java/awt/Focus/KeyStrokeTest.java

Changeset: 9d76c7c6
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-20 07:00:38 +0000
URL:       https://git.openjdk.org/leyden/commit/9d76c7c60ff3133c1078892d7c50a2cfc9ff9c1b

8340418: GHA: MacOS AArch64 bundles can be removed prematurely

Reviewed-by: erikj

! .github/workflows/main.yml

Changeset: 5d611c03
Branch: premain
Author:    SendaoYan <syan at openjdk.org>
Committer: Hamlin Li <mli at openjdk.org>
Date:      2024-09-20 07:34:26 +0000
URL:       https://git.openjdk.org/leyden/commit/5d611c0377d4b5d5495d3941a6a63b128142a2dc

8340439: AArch64: Extra entry declaration for assember test

Reviewed-by: haosun, lmesnik, mli

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

Changeset: a50440fa
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-20 09:21:12 +0000
URL:       https://git.openjdk.org/leyden/commit/a50440fadcd1aa9d8bfddc153dbde6fd55ceb9fa

8340456: Reduce overhead of proxying Object methods in ProxyGenerator

Reviewed-by: liach

! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
- test/micro/org/openjdk/bench/java/lang/reflect/Proxy/ProxyPerf.java
= test/micro/org/openjdk/bench/java/lang/reflect/proxy/ProxyBench.java
+ test/micro/org/openjdk/bench/java/lang/reflect/proxy/ProxyGeneratorBench.java

Changeset: 3ad6e31d
Branch: premain
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-09-20 09:33:31 +0000
URL:       https://git.openjdk.org/leyden/commit/3ad6e31d81bb8a47dc73a6342a6524a901f07687

8340438: RISC-V: minor improvement in base64

Reviewed-by: fyang

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

Changeset: 3c22d83c
Branch: premain
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-09-20 10:07:03 +0000
URL:       https://git.openjdk.org/leyden/commit/3c22d83c0fb9eee2e2b87e607680b96363849c16

8340008: KeyEvent/KeyTyped/Numpad1KeyTyped.java has 15 seconds timeout

Reviewed-by: azvegint, prr

+ test/jdk/java/awt/event/KeyEvent/KeyTyped/Numpad1KeyTyped.java

Changeset: fe80618b
Branch: premain
Author:    Andrey Turbanov <aturbanov at openjdk.org>
Date:      2024-09-20 12:43:57 +0000
URL:       https://git.openjdk.org/leyden/commit/fe80618bf3f80094a93239dd43d4a9b515c5fa18

8339972: Make a few fields in SortingFocusTraversalPolicy static

Reviewed-by: azvegint, aivanov

! src/java.desktop/share/classes/javax/swing/SortingFocusTraversalPolicy.java

Changeset: ae63aaaa
Branch: premain
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-09-20 14:10:39 +0000
URL:       https://git.openjdk.org/leyden/commit/ae63aaaa5847a68542e1483ecf1f0d5a3704e741

8340540: Problemlist DcmdMBeanPermissionsTest.java and SystemDumpMapTest.java

Reviewed-by: kevinw

! test/hotspot/jtreg/ProblemList.txt
! test/jdk/ProblemList.txt

Changeset: 9bcde4ff
Branch: premain
Author:    Amit Kumar <amitkumar at openjdk.org>
Date:      2024-09-20 14:46:10 +0000
URL:       https://git.openjdk.org/leyden/commit/9bcde4ffca20941b010ed454b2fcb948d24b3cac

8338658: New Object to ObjectMonitor mapping: s390x implementation

Reviewed-by: lucy, mdoerr

! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
! src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp
! src/hotspot/cpu/s390/interp_masm_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.hpp
! src/hotspot/cpu/s390/sharedRuntime_s390.cpp
! src/hotspot/share/runtime/basicLock.inline.hpp

Changeset: e087edeb
Branch: premain
Author:    Amit Kumar <amitkumar at openjdk.org>
Date:      2024-09-20 14:48:11 +0000
URL:       https://git.openjdk.org/leyden/commit/e087edeb256a9743d1fdb6c295cb5add78d4552e

8340269: [s390x] TestLargeStub.java failure after 8338123

Reviewed-by: mdoerr, lucy

! src/hotspot/cpu/s390/downcallLinker_s390.cpp

Changeset: 90d3a64b
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-20 16:02:25 +0000
URL:       https://git.openjdk.org/leyden/commit/90d3a64b0afd5810981287b174c6687f0f604f36

8340537: Typo in javadoc of java.util.jar.JarFile

Reviewed-by: mullan, lancea, iris

! src/java.base/share/classes/java/util/jar/JarFile.java

Changeset: ab81197d
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-20 16:11:39 +0000
URL:       https://git.openjdk.org/leyden/commit/ab81197d0ded93b82eea9f8fb35d1647c4520f1e

8339198: Remove tag field from AbstractPoolEntry

Reviewed-by: asotona, redestad

! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java

Changeset: 40fba148
Branch: premain
Author:    Shaojin Wen <swen at openjdk.org>
Date:      2024-09-20 17:54:06 +0000
URL:       https://git.openjdk.org/leyden/commit/40fba148125b9e0d35755b6e6fd701e69d22f7da

8340232: Optimize DataInputStream::readUTF

Reviewed-by: liach, bpb

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

Changeset: 5cffddc6
Branch: premain
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-09-20 18:38:29 +0000
URL:       https://git.openjdk.org/leyden/commit/5cffddc689a0134e1aaacb432d2f0fdd61dd74b1

8338471: Assert deleted methods not returned by CallInfo

Reviewed-by: shade, jwaters, dholmes

! src/hotspot/share/code/compiledIC.cpp
! src/hotspot/share/interpreter/linkResolver.cpp
! src/hotspot/share/interpreter/linkResolver.hpp
! src/hotspot/share/oops/cpCache.cpp

Changeset: 64275e6b
Branch: premain
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2024-09-20 19:34:24 +0000
URL:       https://git.openjdk.org/leyden/commit/64275e6bbf1377c9a9d77fe3c3ed8d4143138f11

8340092: [Linux] containers/systemd/SystemdMemoryAwarenessTest.java failing on some systems

Reviewed-by: mbaesken

= test/hotspot/jtreg/containers/systemd/TEST.properties
! test/lib/jdk/test/lib/containers/systemd/SystemdTestUtils.java

Changeset: 08b25611
Branch: premain
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-09-20 21:27:22 +0000
URL:       https://git.openjdk.org/leyden/commit/08b25611f688ae85c05242afc4cee5b538db4f67

8339781: Better use of Javadoc tags in javax.lang.model

Reviewed-by: jjg

! src/java.compiler/share/classes/javax/annotation/processing/Processor.java
! src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java
! src/java.compiler/share/classes/javax/lang/model/element/NestingKind.java
! src/java.compiler/share/classes/javax/lang/model/util/Types.java

Changeset: 2461263a
Branch: premain
Author:    Shaojin Wen <swen at openjdk.org>
Date:      2024-09-21 00:21:04 +0000
URL:       https://git.openjdk.org/leyden/commit/2461263aac35b25e2a48b6fc84da49e4b553dbc3

8339217: Optimize ClassFile API loadConstant

Reviewed-by: liach, redestad, asotona

! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java

Changeset: ab06a878
Branch: premain
Author:    Shaojin Wen <swen at openjdk.org>
Date:      2024-09-22 01:01:31 +0000
URL:       https://git.openjdk.org/leyden/commit/ab06a878f888827026424530781f0af414a8a611

8340544: Optimize setLocalsFromArg

Reviewed-by: redestad, liach

! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java

Changeset: dd498794
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-09-23 05:48:42 +0000
URL:       https://git.openjdk.org/leyden/commit/dd498794f20df0ac1a73d84e54591905c8a5a5c7

8340524: Remove NarrowPtrStruct

Reviewed-by: shade, jwaters

! src/hotspot/share/oops/compressedOops.cpp
! src/hotspot/share/oops/compressedOops.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/CompressedOops.java

Changeset: 34cddfbe
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-09-23 06:40:33 +0000
URL:       https://git.openjdk.org/leyden/commit/34cddfbedd20d5804cab8044fbc402564e98eb9c

8340387: Update OS detection code to recognize Windows Server 2025

Reviewed-by: mdoerr, jwaters, dholmes

! src/hotspot/os/windows/os_windows.cpp
! src/java.base/windows/native/libjava/java_props_md.c

Changeset: f31f97dd
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-23 07:02:48 +0000
URL:       https://git.openjdk.org/leyden/commit/f31f97ddb6f1fca1a74761e3e3eeef497f8a7416

8340171: CDS: Enhance bitmap truncation

Reviewed-by: matsaave, iklam

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

Changeset: 0f253d11
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-23 07:02:59 +0000
URL:       https://git.openjdk.org/leyden/commit/0f253d11033a26d15ea20df19db6765bb274a848

8340392: Handle OopStorage in location decoder

Reviewed-by: kbarrett, dholmes

! src/hotspot/share/gc/shared/oopStorage.cpp
! src/hotspot/share/gc/shared/oopStorage.hpp
! src/hotspot/share/gc/shared/oopStorage.inline.hpp
! src/hotspot/share/gc/shared/oopStorageSet.cpp
! src/hotspot/share/gc/shared/oopStorageSet.hpp
! src/hotspot/share/runtime/os.cpp
! test/hotspot/gtest/gc/shared/test_oopStorageSet.cpp

Changeset: a07052e8
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-09-23 08:02:16 +0000
URL:       https://git.openjdk.org/leyden/commit/a07052e83d20e107f21fd0d266ab638043531c8a

8340573: Remove unused G1ParScanThreadState::_partial_objarray_chunk_size

Reviewed-by: tschatzl

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

Changeset: bc7c0dc4
Branch: premain
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Date:      2024-09-23 08:02:36 +0000
URL:       https://git.openjdk.org/leyden/commit/bc7c0dc45dcd66d24ece8ebbd5c1b25e131eae67

8340084: Open source AWT Frame related tests

Reviewed-by: psadhukhan, honkar

+ test/jdk/java/awt/Frame/DefaultLocationTest.java
+ test/jdk/java/awt/Frame/EmptyFrameTest.java
+ test/jdk/java/awt/Frame/FrameLayoutTest.java
+ test/jdk/java/awt/Frame/FrameSetMinimumSizeTest.java
+ test/jdk/java/awt/Frame/PackTwiceTest.java

Changeset: 67448b0e
Branch: premain
Author:    Pavel Rappo <prappo at openjdk.org>
Date:      2024-09-23 10:32:58 +0000
URL:       https://git.openjdk.org/leyden/commit/67448b0eb2e83501b9c1dd0c79c7fe03aaef6b09

8339852: Fix typos in java.compiler documentation

Reviewed-by: liach, darcy

! src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java
! src/java.compiler/share/classes/javax/annotation/processing/RoundEnvironment.java
! src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java
! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
! src/java.compiler/share/classes/javax/lang/model/element/AnnotationMirror.java
! src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java
! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java
! src/java.compiler/share/classes/javax/lang/model/element/package-info.java
! src/java.compiler/share/classes/javax/lang/model/util/Elements.java
! src/java.compiler/share/classes/javax/lang/model/util/Types.java
! src/java.compiler/share/classes/javax/tools/ForwardingFileObject.java
! src/java.compiler/share/classes/javax/tools/ForwardingJavaFileManager.java
! src/java.compiler/share/classes/javax/tools/ForwardingJavaFileObject.java
! src/java.compiler/share/classes/javax/tools/JavaFileManager.java
! src/java.compiler/share/classes/javax/tools/StandardJavaFileManager.java
! src/java.compiler/share/classes/javax/tools/ToolProvider.java

Changeset: 384deda6
Branch: premain
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-09-23 10:57:43 +0000
URL:       https://git.openjdk.org/leyden/commit/384deda65fd63e23d4caaaa9762f2ac80de78029

8325949: Create an internal utility method for creating VarHandle instances

Reviewed-by: rriggs

! src/java.base/share/classes/java/lang/ThreadBuilders.java
! src/java.base/share/classes/java/lang/invoke/Invokers.java
! src/java.base/share/classes/java/net/Socket.java
! src/java.base/share/classes/java/nio/channels/SelectionKey.java
! src/java.base/share/classes/java/nio/channels/spi/AbstractSelectionKey.java
! src/java.base/share/classes/java/nio/channels/spi/AbstractSelector.java
! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java
! src/java.base/share/classes/java/util/concurrent/Exchanger.java
! src/java.base/share/classes/java/util/concurrent/FutureTask.java
! src/java.base/share/classes/java/util/concurrent/Phaser.java
! src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java
! src/java.base/share/classes/java/util/concurrent/SubmissionPublisher.java
! src/java.base/share/classes/java/util/concurrent/ThreadPerTaskExecutor.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicBoolean.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicMarkableReference.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReference.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java
! src/java.base/share/classes/java/util/concurrent/atomic/Striped64.java
! src/java.base/share/classes/java/util/stream/ForEachOps.java
! src/java.base/share/classes/java/util/stream/GathererOp.java
! src/java.base/share/classes/jdk/internal/foreign/ConfinedSession.java
! src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java
! src/java.base/share/classes/jdk/internal/foreign/SharedSession.java
! src/java.base/share/classes/jdk/internal/foreign/abi/DowncallLinker.java
! src/java.base/share/classes/jdk/internal/foreign/layout/AbstractLayout.java
+ src/java.base/share/classes/jdk/internal/invoke/MhUtil.java
! src/java.base/share/classes/jdk/internal/misc/ThreadFlock.java
! src/java.base/share/classes/jdk/internal/reflect/DirectMethodHandleAccessor.java
! src/java.base/share/classes/jdk/internal/vm/SharedThreadContainer.java
! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java

Changeset: 37ec80df
Branch: premain
Author:    Joel Sikstr?m <joel.sikstrom at oracle.com>
Committer: Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-23 12:28:43 +0000
URL:       https://git.openjdk.org/leyden/commit/37ec80df8d3b014292fc3d31a1b2aad4e8218ea5

8339161: ZGC: Remove unused remembered sets

Reviewed-by: aboldtch, stefank

! src/hotspot/share/gc/z/zHeap.cpp
! src/hotspot/share/gc/z/zPage.cpp
! src/hotspot/share/gc/z/zPage.hpp
! src/hotspot/share/gc/z/zPageAllocator.cpp
! src/hotspot/share/gc/z/zRelocate.cpp
! src/hotspot/share/gc/z/zRememberedSet.cpp
! src/hotspot/share/gc/z/zRememberedSet.hpp

Changeset: 63e611cd
Branch: premain
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2024-09-23 12:30:30 +0000
URL:       https://git.openjdk.org/leyden/commit/63e611cd5d7eb4fc6ea6633ff9123e4bee5f5993

8335334: Stress mode to randomly execute unstable if traps

Reviewed-by: chagedorn, kvn

! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/cfgnode.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/ifnode.cpp
! src/hotspot/share/opto/parse.hpp
! src/hotspot/share/opto/parse2.cpp
! test/hotspot/jtreg/compiler/arguments/TestStressOptions.java
! test/hotspot/jtreg/compiler/c2/irTests/TestPrunedExHandler.java
! test/hotspot/jtreg/compiler/cha/StrengthReduceInterfaceCall.java
! test/hotspot/jtreg/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java
! test/hotspot/jtreg/compiler/rangechecks/TestExplicitRangeChecks.java
! test/hotspot/jtreg/compiler/uncommontrap/TestUnstableIfTrap.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicBooleanOpTest.java
! test/hotspot/jtreg/compiler/whitebox/DeoptimizeFramesTest.java
! test/jdk/jdk/jfr/event/compiler/TestDeoptimization.java

Changeset: a9b0f9cc
Branch: premain
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
Date:      2024-09-23 13:58:00 +0000
URL:       https://git.openjdk.org/leyden/commit/a9b0f9ccbf98c6b90626fcd7087fa8eeb0c168eb

8340393: Open source closed choice tests #2

Reviewed-by: psadhukhan

+ test/jdk/java/awt/Choice/CheckChoiceTest.java
+ test/jdk/java/awt/Choice/ChoiceBigTest.java
+ test/jdk/java/awt/Choice/ChoiceFocusTest.java
+ test/jdk/java/awt/Choice/DisabledList.java

Changeset: ea8f35b9
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-23 14:33:17 +0000
URL:       https://git.openjdk.org/leyden/commit/ea8f35b98e618bfa55371e45b3ef61fa5289dd94

8340183: Shenandoah: Incorrect match for clone barrier in is_gc_barrier_node

Reviewed-by: roland, rkennke

! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.hpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp

Changeset: 0f9f7775
Branch: premain
Author:    Lance Andersen <lancea at openjdk.org>
Date:      2024-09-23 16:07:12 +0000
URL:       https://git.openjdk.org/leyden/commit/0f9f777520c5341be1e9f985f41304a297b08936

8336025: Improve ZipOutputSream validation of MAX CEN Header field limits

Reviewed-by: alanb

! src/java.base/share/classes/java/util/zip/ZipEntry.java
! src/java.base/share/classes/java/util/zip/ZipOutputStream.java
! test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java
+ test/jdk/java/util/zip/ZipOutputStream/ZipOutputStreamMaxCenHdrTest.java

Changeset: c6f1d5f3
Branch: premain
Author:    Francisco Ferrari Bihurriet <fferrari at openjdk.org>
Date:      2024-09-23 17:45:38 +0000
URL:       https://git.openjdk.org/leyden/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab

8319332: Security properties files inclusion

Co-authored-by: Francisco Ferrari Bihurriet <fferrari at openjdk.org>
Co-authored-by: Martin Balao <mbalao at openjdk.org>
Reviewed-by: weijun, mullan, kdriver

! src/java.base/share/classes/java/security/Security.java
! src/java.base/share/classes/sun/security/util/PropertyExpander.java
! src/java.base/share/conf/security/java.security
! test/jdk/java/security/Security/ConfigFileTest.java
- test/jdk/java/security/Security/override.props
! test/jdk/java/security/Security/signedfirst/DynStatic.java

Changeset: 833ff299
Branch: premain
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-09-23 18:25:12 +0000
URL:       https://git.openjdk.org/leyden/commit/833ff29983e0d433ccd4c7e946b15e42045faeaa

8340461: Amend description for logArea

Reviewed-by: azvegint, prr

! test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

Changeset: 8dcf7b8f
Branch: premain
Author:    Phil Race <prr at openjdk.org>
Date:      2024-09-23 18:26:52 +0000
URL:       https://git.openjdk.org/leyden/commit/8dcf7b8fa7b17bf34c62c561c6ed78e8080df1ff

8340411: open source several 2D imaging tests

Reviewed-by: azvegint

+ test/jdk/sun/awt/image/BytePackedRaster/DitherTest.java
+ test/jdk/sun/awt/image/BytePackedRaster/MultiOp.java
+ test/jdk/sun/awt/image/ImageRepresentation/ByteBinaryBitmask.java
+ test/jdk/sun/awt/image/ImageRepresentation/CustomSourceCM.java

Changeset: e97f0fe1
Branch: premain
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-09-23 18:31:31 +0000
URL:       https://git.openjdk.org/leyden/commit/e97f0fe1b4046bfcc40e85ba1bee4f4c40053300

8340365: Position the first window of a window list

Reviewed-by: azvegint, prr

! test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

Changeset: cd796e0a
Branch: premain
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2024-09-24 00:13:49 +0000
URL:       https://git.openjdk.org/leyden/commit/cd796e0aef321d46c96f79dc5446d095b8a30e60

8338918: Remove non translated file name from WinResources resource bundle

Reviewed-by: jlu, almatvee

! src/jdk.jpackage/share/classes/jdk/jpackage/internal/I18N.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties
= src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResourcesNoL10N.properties
= src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResourcesNoL10N_de.properties
= src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResourcesNoL10N_ja.properties
= src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResourcesNoL10N_zh_CN.properties
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties

Changeset: c8ae8480
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-09-24 00:37:21 +0000
URL:       https://git.openjdk.org/leyden/commit/c8ae8480496d56a8e51b9f5a6df50c70a429672f

8340707: ProblemList applications/ctw/modules/java_base.java due to JDK-8340683

Reviewed-by: darcy

! test/hotspot/jtreg/ProblemList.txt

Changeset: 40cde003
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-24 01:47:57 +0000
URL:       https://git.openjdk.org/leyden/commit/40cde003e8061a0eb6b0214d5a44325c3d55cdc6

8340114: Remove outdated SelectVersion() function from the launcher and update the code comments explaining the code flow

Reviewed-by: dholmes, alanb

! src/java.base/macosx/native/libjli/java_md_macosx.m
! src/java.base/share/native/libjli/emessages.h
! src/java.base/share/native/libjli/java.c
! src/java.base/share/native/libjli/java.h
! src/java.base/share/native/libjli/manifest_info.h
! src/java.base/share/native/libjli/parse_manifest.c
! src/java.base/unix/native/libjli/java_md.c
- test/jdk/tools/launcher/MultipleJRERemoved.java

Changeset: 3411f9df
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-24 02:08:06 +0000
URL:       https://git.openjdk.org/leyden/commit/3411f9dff79c2e7cb7ce8ebf036f8b3fd9bb647d

8339995: Open source several AWT focus tests - series 6

Reviewed-by: prr

! test/jdk/ProblemList.txt
+ test/jdk/java/awt/Focus/ConsumedKeyEventTest.java
+ test/jdk/java/awt/Focus/EmptyWindowKeyTest.java
+ test/jdk/java/awt/Focus/InactiveFocusRace.java
+ test/jdk/java/awt/Focus/InitialPrintDlgFocusTest.java

Changeset: 865d99f6
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-24 02:08:20 +0000
URL:       https://git.openjdk.org/leyden/commit/865d99f63475799b9a0503a3dcc21a7534b014d1

8340596: Remove dead code from RequiresSetenv function in java.base/unix/native/libjli/java_md.c

Reviewed-by: dholmes

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

Changeset: 6c91a16f
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-24 02:09:42 +0000
URL:       https://git.openjdk.org/leyden/commit/6c91a16f16cbeb1bb0a79459e7db1fd9f576e743

8340367: Opensource few AWT image tests

Reviewed-by: prr

+ test/jdk/java/awt/image/BufferedImage/GrayAATextTest.java
+ test/jdk/java/awt/image/GrayAlpha.java
+ test/jdk/java/awt/image/ImageOffsetTest.java
+ test/jdk/java/awt/image/TransformImage.java
= test/jdk/java/awt/image/duke.gif

Changeset: 4098acc2
Branch: premain
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2024-09-24 05:35:12 +0000
URL:       https://git.openjdk.org/leyden/commit/4098acc200e608369ac1631dcc8513ea797bd59e

8340146: ZGC: TestAllocateHeapAt.java should not run with UseLargePages

Reviewed-by: tschatzl, stefank

! test/hotspot/jtreg/gc/x/TestAllocateHeapAt.java
! test/hotspot/jtreg/gc/z/TestAllocateHeapAt.java
! test/jtreg-ext/requires/VMProps.java

Changeset: 1dd60b62
Branch: premain
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-09-24 06:47:20 +0000
URL:       https://git.openjdk.org/leyden/commit/1dd60b62e384090b13a08d2afa62e49ef52bc46c

8323688: C2: Fix UB of jlong overflow in PhaseIdealLoop::is_counted_loop()

Reviewed-by: thartmann, kvn

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

Changeset: 88801cae
Branch: premain
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2024-09-24 07:09:10 +0000
URL:       https://git.openjdk.org/leyden/commit/88801caef6ccdc5ba9ade2af830f3b3cd96e1467

8340590: RISC-V: C2: Small improvement to vector gather load and scatter store

Reviewed-by: fyang, dzhang

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

Changeset: 9176f681
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-09-24 07:22:27 +0000
URL:       https://git.openjdk.org/leyden/commit/9176f6810ef914579b8ca8e3bc20a0fdf3a934c8

8340623: Remove outdated PROCESSOR_ARCHITECTURE_IA64 from Windows coding

Reviewed-by: alanb, dholmes

! src/java.base/windows/native/libjava/java_props_md.c

Changeset: e60e8821
Branch: premain
Author:    Afshin Zafari <azafari at openjdk.org>
Date:      2024-09-24 07:56:14 +0000
URL:       https://git.openjdk.org/leyden/commit/e60e8821568a74269340417fece2acb71f633098

8335167: Test runtime/Thread/TestAlwaysPreTouchStacks.java failed with Expected a higher ratio between stack committed and reserved

Reviewed-by: stuefe, dholmes, gziemski

! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/runtime/Thread/TestAlwaysPreTouchStacks.java

Changeset: 44024826
Branch: premain
Author:    Yudi Zheng <yzheng at openjdk.org>
Date:      2024-09-24 08:25:06 +0000
URL:       https://git.openjdk.org/leyden/commit/44024826e52373d1613ec366e3f5a9d5bbaefa41

8340585: [JVMCI] compiler/unsafe/UnsafeGetStableArrayElement.java fails with -XX:-UseCompressedClassPointers

Reviewed-by: dnsimon

! test/hotspot/jtreg/compiler/unsafe/UnsafeGetStableArrayElement.java

Changeset: 4cd8c75a
Branch: premain
Author:    Tomas Zezula <tzezula at openjdk.org>
Committer: Doug Simon <dnsimon at openjdk.org>
Date:      2024-09-24 10:19:38 +0000
URL:       https://git.openjdk.org/leyden/commit/4cd8c75a55163be33917b1fba9f360ea816f3aa9

8340398: [JVMCI] Unintuitive behavior of UseJVMCICompiler option

Reviewed-by: dnsimon

! src/hotspot/share/jvmci/jvmci_globals.cpp
! src/hotspot/share/jvmci/jvmci_globals.hpp
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJVMCICompilerConfig.java

Changeset: 3e673d9e
Branch: premain
Author:    Pavel Rappo <prappo at openjdk.org>
Date:      2024-09-24 10:48:35 +0000
URL:       https://git.openjdk.org/leyden/commit/3e673d9e46ddb464263ff76f385ca5bf98a0b19d

8340680: Fix typos in javax.lang.model.SourceVersion

Reviewed-by: darcy, iris

! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java

Changeset: e1c4d303
Branch: premain
Author:    Kuai Wei <kuaiwei.kw at alibaba-inc.com>
Date:      2024-09-24 11:08:36 +0000
URL:       https://git.openjdk.org/leyden/commit/e1c4d3039f6b5106ce3f65d50f607eacc2a8d168

8339299: C1 will miss type profile when inline final method

Reviewed-by: lmesnik, vlivanov

! src/hotspot/share/c1/c1_LIR.hpp
+ test/hotspot/jtreg/compiler/cha/TypeProfileFinalMethod.java

Changeset: 49d15edd
Branch: premain
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2024-09-24 12:43:00 +0000
URL:       https://git.openjdk.org/leyden/commit/49d15edd31c863faf3722af1bae8b50662ecf71f

8340657: [PPC64] SA determines wrong unextendedSP

Reviewed-by: ysuenaga, mbaesken

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java

Changeset: 3c97d243
Branch: premain
Author:    George Adams <gdams at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
Date:      2024-09-24 12:50:33 +0000
URL:       https://git.openjdk.org/leyden/commit/3c97d2437d34d2db47f3607fbb95ac3b8e2ec60b

8340383: VM issues warning failure to find kernel32.dll on Windows nanoserver

Reviewed-by: dholmes, jwaters

! src/hotspot/os/windows/os_windows.cpp

Changeset: 279086d4
Branch: premain
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2024-09-24 13:16:43 +0000
URL:       https://git.openjdk.org/leyden/commit/279086d4ce7e05972e099022e8045f39680dd4e8

8340408: Shenandoah: Remove redundant task stats printing code in ShenandoahTaskQueue

Reviewed-by: shade, wkemper

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.cpp
! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp

Changeset: caa751c5
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-24 14:28:05 +0000
URL:       https://git.openjdk.org/leyden/commit/caa751c561f55bc59a6195a947d7b75515b5d2c0

8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)

Reviewed-by: asotona, redestad

! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
! src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java
! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java
! test/jdk/jdk/classfile/ConstantDescSymbolsTest.java
! test/jdk/jdk/classfile/UtilTest.java
+ test/jdk/jdk/classfile/java.base/jdk/internal/classfile/impl/UtilAccess.java
+ test/micro/org/openjdk/bench/jdk/classfile/ConstantPoolBuildingClassEntry.java

Changeset: 85aed877
Branch: premain
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
Date:      2024-09-24 14:40:38 +0000
URL:       https://git.openjdk.org/leyden/commit/85aed877960ef86b483b76ce4fcf95602ae2b924

8338405: JFR: Use FILE type for dcmds

Reviewed-by: egahlin, lmesnik

! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/AbstractDCmd.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/ArgumentParser.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdDump.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStop.java

Changeset: 2669e22b
Branch: premain
Author:    Andrew Dinn <adinn at openjdk.org>
Date:      2024-09-24 14:51:28 +0000
URL:       https://git.openjdk.org/leyden/commit/2669e22b76c99c1e41a324099154b561e0433b56

8340793: Fix client builds after JDK-8337987

Reviewed-by: shade, fyang

! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/arm/sharedRuntime_arm.cpp
! src/hotspot/cpu/s390/sharedRuntime_s390.cpp

Changeset: 212e3293
Branch: premain
Author:    vamsi-parasa <srinivas.vamsi.parasa at intel.com>
Date:      2024-09-24 15:11:13 +0000
URL:       https://git.openjdk.org/leyden/commit/212e32931cafe446d94219d6c3ffd92261984dff

8338694: x86_64 intrinsic for tanh using libm

Reviewed-by: kvn, jbhateja, sgibbons, sviswanathan

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.hpp
+ src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp
! src/hotspot/cpu/x86/templateInterpreterGenerator_x86_32.cpp
! src/hotspot/cpu/x86/templateInterpreterGenerator_x86_64.cpp
! src/hotspot/share/c1/c1_Compiler.cpp
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/classfile/vmIntrinsics.cpp
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/interpreter/abstractInterpreter.cpp
! src/hotspot/share/interpreter/abstractInterpreter.hpp
! src/hotspot/share/interpreter/templateInterpreterGenerator.cpp
! src/hotspot/share/interpreter/zero/zeroInterpreterGenerator.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/runtime/stubRoutines.cpp
! src/hotspot/share/runtime/stubRoutines.hpp
! src/java.base/share/classes/java/lang/Math.java
! test/jdk/java/lang/Math/HyperbolicTests.java

Changeset: 90c2c0b4
Branch: premain
Author:    Phil Race <prr at openjdk.org>
Date:      2024-09-24 18:07:33 +0000
URL:       https://git.openjdk.org/leyden/commit/90c2c0b4ad4ee7d2ea149aea771cf81bd666b1dc

8340143: Open source several Java2D rendering loop tests.

Reviewed-by: psadhukhan

+ test/jdk/sun/java2d/loops/ARGBBgToRGB.java
+ test/jdk/sun/java2d/loops/CopyNegative.java
+ test/jdk/sun/java2d/loops/DitheredSolidFill.java
+ test/jdk/sun/java2d/loops/OffsetCalculationTest.java
+ test/jdk/sun/java2d/loops/XORClearRect.java

Changeset: 8c08c43a
Branch: premain
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
Date:      2024-09-24 18:56:22 +0000
URL:       https://git.openjdk.org/leyden/commit/8c08c43a34b7a237c0281ef58594af4f263ba3ca

8340433: Open source closed choice tests #3

Reviewed-by: honkar, prr

+ test/jdk/java/awt/Choice/ChoicePosTest.java
+ test/jdk/java/awt/Choice/DeadlockTest.java
+ test/jdk/java/awt/Choice/SetFontTest.java

Changeset: e3d80f1e
Branch: premain
Author:    Artur Barashev <artur.barashev at oracle.com>
Committer: Sean Mullan <mullan at openjdk.org>
Date:      2024-09-24 18:57:58 +0000
URL:       https://git.openjdk.org/leyden/commit/e3d80f1e1e8b5d503f13b8037172e3dac29e27ad

8340670: Policy.UNSUPPORTED_EMPTY_COLLECTION.isReadOnly does not return true

Reviewed-by: mullan

! src/java.base/share/classes/java/security/Policy.java

Changeset: b639661e
Branch: premain
Author:    George Adams <gdams at openjdk.org>
Date:      2024-09-24 19:35:59 +0000
URL:       https://git.openjdk.org/leyden/commit/b639661e797fb52ce32ce397a153c886fdc40f53

8340804: doc/building.md update Xcode instructions to note that full install is required

Reviewed-by: erikj, jwaters

! doc/building.html
! doc/building.md

Changeset: 0b8c9f6d
Branch: premain
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2024-09-24 20:09:40 +0000
URL:       https://git.openjdk.org/leyden/commit/0b8c9f6d2397dcb480dc5ae109607d86f2b15619

8338525: Leading and trailing code blocks by indentation

Reviewed-by: hannesw, prappo

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java
! test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdownCodeBlocks.java
! test/langtools/tools/javac/doctree/DocCommentTester.java
! test/langtools/tools/javac/doctree/MarkdownTest.java

Changeset: c0fcb258
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-25 01:45:04 +0000
URL:       https://git.openjdk.org/leyden/commit/c0fcb258bbd02892267970dc4bc082dc7761f074

8340717: Remove unused function declarations from java.c/java.h of the launcher

Reviewed-by: alanb, dholmes, shade, jwaters

! src/java.base/share/native/libjli/java.c
! src/java.base/share/native/libjli/java.h

Changeset: a37bb2e0
Branch: premain
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2024-09-25 02:29:06 +0000
URL:       https://git.openjdk.org/leyden/commit/a37bb2e0372a7c074c88d31824fc418a47f63405

8340643: RISC-V: Small refactoring for sub/subw macro-assembler routines

Reviewed-by: fyang, luhenry

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

Changeset: 9bcc7b66
Branch: premain
Author:    Shaojin Wen <swen at openjdk.org>
Date:      2024-09-25 02:30:46 +0000
URL:       https://git.openjdk.org/leyden/commit/9bcc7b66de6495d3da8fc7f30a2a88187dbe847d

8340708: Optimize StackMapGenerator::processMethod

Reviewed-by: liach

! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java

Changeset: 2d38af61
Branch: premain
Author:    Shaojin Wen <swen at openjdk.org>
Date:      2024-09-25 02:32:29 +0000
URL:       https://git.openjdk.org/leyden/commit/2d38af61e4133ca98d5a98b3cfb6a6dde2877026

8340587: Optimize StackMapGenerator$Frame::checkAssignableTo

Reviewed-by: liach

! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java

Changeset: 2e0554a6
Branch: premain
Author:    Shaojin Wen <swen at openjdk.org>
Date:      2024-09-25 02:35:41 +0000
URL:       https://git.openjdk.org/leyden/commit/2e0554a69548dae6e8ce9eec48c82e08dd3c1ffa

8340710: Optimize DirectClassBuilder::build

Reviewed-by: liach

! src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectClassBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java

Changeset: b1f8d2ea
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-25 03:07:45 +0000
URL:       https://git.openjdk.org/leyden/commit/b1f8d2ea76322a89eea84851a1e791f52c31261b

8339935: Open source several AWT focus tests - series 5

Reviewed-by: prr

+ test/jdk/java/awt/Focus/DeiconifyTest.java
+ test/jdk/java/awt/Focus/HiddenTraversalTest.java
+ test/jdk/java/awt/Focus/LightweightPopupTest.java
+ test/jdk/java/awt/Focus/ProxiedWindowHideTest.java

Changeset: 97a3933f
Branch: premain
Author:    Robbin Ehn <rehn at openjdk.org>
Date:      2024-09-25 08:11:00 +0000
URL:       https://git.openjdk.org/leyden/commit/97a3933f1be2cabfc574689bb60618fe6fa3a8a4

8339771: RISC-V: Reduce icache flushes

Reviewed-by: fyang, mli, luhenry

! src/hotspot/cpu/riscv/assembler_riscv.hpp
! src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.cpp
! src/hotspot/cpu/riscv/globals_riscv.hpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp
! src/hotspot/cpu/riscv/relocInfo_riscv.cpp
! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp
! src/hotspot/cpu/riscv/vm_version_riscv.hpp
! src/hotspot/os_cpu/linux_riscv/orderAccess_linux_riscv.hpp
! src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp

Changeset: 9806d213
Branch: premain
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-09-25 08:13:25 +0000
URL:       https://git.openjdk.org/leyden/commit/9806d2139cb5994effdee3f7bc6b23eb81858ed3

8340808: RISC-V: Client build fails after JDK-8339738

Reviewed-by: fyang

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

Changeset: 1b9898a4
Branch: premain
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2024-09-25 09:26:06 +0000
URL:       https://git.openjdk.org/leyden/commit/1b9898a44fd3f8159a7184053ef50cba55419d6e

8340843: [PPC64/s390x] Error: ShouldNotReachHere() in TemplateInterpreterGenerator::generate_math_entry after 8338694

Reviewed-by: mbaesken, amitkumar

! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
! src/hotspot/cpu/s390/templateInterpreterGenerator_s390.cpp

Changeset: 120463dc
Branch: premain
Author:    Hannes Walln?fer <hannesw at openjdk.org>
Date:      2024-09-25 12:15:07 +0000
URL:       https://git.openjdk.org/leyden/commit/120463dc90d717bffb2bd0d5e6b1ea707f5d1b42

8339541: CSS rule is not specific enough

Reviewed-by: jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/stylesheet.css

Changeset: d8790aa0
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-25 13:04:46 +0000
URL:       https://git.openjdk.org/leyden/commit/d8790aa0489fe49b499535c31cdfb691003792ff

8340885: Desugar ZipCoder.Comparison

Reviewed-by: lancea, eirbjo

! src/java.base/share/classes/java/util/zip/ZipCoder.java
! src/java.base/share/classes/java/util/zip/ZipFile.java

Changeset: 083b9808
Branch: premain
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2024-09-25 13:12:47 +0000
URL:       https://git.openjdk.org/leyden/commit/083b98083136933fc51499181f85ca30a77da9e1

8340568: Incorrect escaping of single quotes when pretty-printing character literals

Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java
+ test/langtools/tools/javac/tree/PrettyCharLiteral.java

Changeset: fb703258
Branch: premain
Author:    Leonov Kirill <91743110+kirleo2 at users.noreply.github.com>
Date:      2024-09-25 13:18:25 +0000
URL:       https://git.openjdk.org/leyden/commit/fb703258774ca14a6a239fc6d47a37e021e6036a

8338583: NMT: Malloc overhead is calculated incorrectly

Reviewed-by: azafari, yan, gziemski

! src/hotspot/share/nmt/mallocHeader.hpp
! src/hotspot/share/nmt/mallocTracker.hpp
! src/hotspot/share/nmt/memTracker.hpp

Changeset: 0474f020
Branch: premain
Author:    George Adams <gdams at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
Date:      2024-09-25 16:25:23 +0000
URL:       https://git.openjdk.org/leyden/commit/0474f020bf276c761f46bc8ba0873ed90a8fd19b

8340815: Add SECURITY.md file

Reviewed-by: mr, jwaters, erikj

+ SECURITY.md

Changeset: 81b5f097
Branch: premain
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-09-25 16:36:28 +0000
URL:       https://git.openjdk.org/leyden/commit/81b5f0974903accc738c07cdf7be09fa6ea8fbdd

8340946: Add vmTestbase/gc/memory/Nio/Nio.java and java/nio/Buffer/LimitDirectMemory.java to problem list

Reviewed-by: liach, dcubed, alanb

! test/hotspot/jtreg/ProblemList.txt
! test/jdk/ProblemList.txt

Changeset: 0e0b0b0d
Branch: premain
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Date:      2024-09-25 16:36:44 +0000
URL:       https://git.openjdk.org/leyden/commit/0e0b0b0d2626cda032f1500e64f6729554e47038

8340684: Reading from an input stream backed by a closed ZipFile has no test coverage

Reviewed-by: lancea

+ test/jdk/java/util/zip/ZipFile/ReadAfterClose.java

Changeset: f7bc9ba5
Branch: premain
Author:    Alexander Zuev <kizune at openjdk.org>
Date:      2024-09-25 16:46:49 +0000
URL:       https://git.openjdk.org/leyden/commit/f7bc9ba552cf913eef2131b964c48f1b4b55131c

8340228: Open source couple more miscellaneous AWT tests

Reviewed-by: prr

+ test/jdk/java/awt/Desktop/EditAndPrintTest/EditAndPrintTest.java
+ test/jdk/java/awt/TextField/GetTextTest/GetTextTest.java
+ test/jdk/java/awt/TextField/SetEchoCharTest3/SetEchoCharTest3.java

Changeset: 1b2d40ad
Branch: premain
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2024-09-25 17:19:02 +0000
URL:       https://git.openjdk.org/leyden/commit/1b2d40addfc5e32229418d29ae90fb440720479e

8340956: ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all

Reviewed-by: liach, alanb, darcy, dfuchs

! test/jdk/ProblemList.txt

Changeset: df1959fd
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-25 18:29:30 +0000
URL:       https://git.openjdk.org/leyden/commit/df1959fd7a57f11839d58858bab4ea61f5b2bb8d

8340838: Clean up MutableCallSite to use explicit release fence instead of AtomicInteger

Reviewed-by: jrose, redestad, shade

! src/java.base/share/classes/java/lang/invoke/MutableCallSite.java

Changeset: 84751cbf
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-25 18:31:24 +0000
URL:       https://git.openjdk.org/leyden/commit/84751cbfddf69bd9ed6bc5c39f8e056009440331

8340831: Simplify simple validation for class definition in MethodHandles.Lookup

Reviewed-by: redestad

! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/jdk/internal/misc/VM.java

Changeset: 8f756196
Branch: premain
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2024-09-25 18:51:16 +0000
URL:       https://git.openjdk.org/leyden/commit/8f756196b430af67a8e31a13811a183d52df8497

8340864: Remove unused lines related to vmClasses

Reviewed-by: shade, kvn

! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/classfile/vmClasses.cpp
! src/hotspot/share/classfile/vmClasses.hpp

Changeset: a3a64c76
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-09-26 08:40:44 +0000
URL:       https://git.openjdk.org/leyden/commit/a3a64c76c815ec05bc3d6c0e8ef57de8dc0d0682

Merge branch 'master' into premain

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
! src/hotspot/cpu/s390/templateInterpreterGenerator_s390.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/c1/c1_Compilation.cpp
! src/hotspot/share/c1/c1_Compiler.cpp
! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/filemap.hpp
! src/hotspot/share/cds/heapShared.hpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/ci/ciEnv.hpp
! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/classLoaderExt.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/vmClasses.cpp
! src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/compiler/oopMap.cpp
! src/hotspot/share/interpreter/linkResolver.cpp
! src/hotspot/share/interpreter/linkResolver.hpp
! src/hotspot/share/interpreter/templateInterpreterGenerator.cpp
! src/hotspot/share/memory/allocation.cpp
! src/hotspot/share/memory/allocation.hpp
! src/hotspot/share/memory/metadataFactory.hpp
! src/hotspot/share/memory/metaspace.cpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/memory/universe.hpp
! src/hotspot/share/memory/virtualspace.cpp
! src/hotspot/share/nmt/virtualMemoryTracker.cpp
! src/hotspot/share/oops/array.hpp
! src/hotspot/share/oops/array.inline.hpp
! src/hotspot/share/oops/compressedOops.cpp
! src/hotspot/share/oops/cpCache.cpp
! src/hotspot/share/oops/oop.cpp
! src/hotspot/share/oops/trainingData.hpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/parse.hpp
! src/hotspot/share/opto/parse2.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvmtiEnv.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/stubRoutines.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/threads.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/LambdaForm.java
! src/java.base/share/native/libjli/java.c
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/runtime/cds/appcds/ClassPathAttr.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/IncompatibleOptions.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsHumongous.java
! test/jtreg-ext/requires/VMProps.java
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
! src/hotspot/cpu/s390/templateInterpreterGenerator_s390.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/c1/c1_Compilation.cpp
! src/hotspot/share/c1/c1_Compiler.cpp
! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/filemap.hpp
! src/hotspot/share/cds/heapShared.hpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/ci/ciEnv.hpp
! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/classLoaderExt.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/vmClasses.cpp
+ src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/compiler/oopMap.cpp
! src/hotspot/share/interpreter/linkResolver.cpp
! src/hotspot/share/interpreter/linkResolver.hpp
! src/hotspot/share/interpreter/templateInterpreterGenerator.cpp
! src/hotspot/share/memory/allocation.cpp
! src/hotspot/share/memory/allocation.hpp
! src/hotspot/share/memory/metadataFactory.hpp
! src/hotspot/share/memory/metaspace.cpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/memory/universe.hpp
! src/hotspot/share/memory/virtualspace.cpp
! src/hotspot/share/nmt/virtualMemoryTracker.cpp
! src/hotspot/share/oops/array.hpp
! src/hotspot/share/oops/array.inline.hpp
! src/hotspot/share/oops/compressedOops.cpp
! src/hotspot/share/oops/cpCache.cpp
! src/hotspot/share/oops/oop.cpp
+ src/hotspot/share/oops/trainingData.hpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/parse.hpp
! src/hotspot/share/opto/parse2.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvmtiEnv.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/stubRoutines.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/threads.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/LambdaForm.java
! src/java.base/share/native/libjli/java.c
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/runtime/cds/appcds/ClassPathAttr.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/IncompatibleOptions.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsHumongous.java
! test/jtreg-ext/requires/VMProps.java


From shade at openjdk.org  Fri Sep 27 08:07:20 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 27 Sep 2024 08:07:20 GMT
Subject: RFR: FileMapInfo::write_bitmap_region after premain merge
Message-ID: <8GS1slv5sXiJzs1dRPjQiiTpedBpYE4Xz_LWoNOFDi0=.60f512b8-33f4-410f-8ec2-6ff34d62585c@github.com>

I think there is a bad merge in `FileMapInfo::write_bitmap_region`.

The symptom on `runtime/cds` tests suggests we have have the overflow on `bitmap` buffer array we have just allocated, which suggests we miscalculated the size for it:


#  Internal Error (/home/shade/trunks/shipilev-leyden/src/hotspot/share/nmt/mallocHeader.inline.hpp:107), pid=2332848, tid=2332849
#  fatal error: NMT corruption: Block at 0x000078422d0c3120: footer canary broken at 0x000078422d0f8618 (buffer overflow?)

Stack: [0x0000784232100000,0x0000784232200000],  sp=0x00007842321fcfe0,  free space=1011k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x145e785]  MallocHeader* MallocHeader::resolve_checked_impl<void*, MallocHeader*>(void*)+0x145  (mallocHeader.inline.hpp:107)
V  [libjvm.so+0x145d599]  MallocTracker::record_free_block(void*)+0x29  (mallocHeader.inline.hpp:113)
V  [libjvm.so+0x15dc42a]  os::free(void*)+0x6a  (memTracker.hpp:94)
V  [libjvm.so+0x64a487]  ArchiveBuilder::write_archive(FileMapInfo*, ArchiveHeapInfo*)+0x457  (archiveBuilder.cpp:1569)
V  [libjvm.so+0x14d3ece]  MetaspaceShared::write_static_archive(ArchiveBuilder*, FileMapInfo*, ArchiveHeapInfo*)+0x4e  (metaspaceShared.cpp:1016)
V  [libjvm.so+0x14d9066]  MetaspaceShared::preload_and_dump_impl(StaticArchiveBuilder&, JavaThread*)+0x5c6  (metaspaceShared.cpp:999)
V  [libjvm.so+0x14d9217]  MetaspaceShared::preload_and_dump(JavaThread*)+0x87  (metaspaceShared.cpp:792)
V  [libjvm.so+0x1a4cd3c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x122c  (threads.cpp:909)
V  [libjvm.so+0x1078e78]  JNI_CreateJavaVM+0x58  (jni.cpp:3594)
C  [libjli.so+0x4903]  JavaMain+0x93  (java.c:1494)
C  [libjli.so+0x7f0d]  ThreadJavaMain+0xd  (java_md.c:633)


Additional testing:
 - [x] Linux x86_64 server fastdebug, `runtime/cds` now passes

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/leyden/pull/24/files
  Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=24&range=00
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/leyden/pull/24.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/24/head:pull/24

PR: https://git.openjdk.org/leyden/pull/24

From shade at openjdk.org  Fri Sep 27 08:07:20 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 27 Sep 2024 08:07:20 GMT
Subject: RFR: FileMapInfo::write_bitmap_region after premain merge
In-Reply-To: <8GS1slv5sXiJzs1dRPjQiiTpedBpYE4Xz_LWoNOFDi0=.60f512b8-33f4-410f-8ec2-6ff34d62585c@github.com>
References: <8GS1slv5sXiJzs1dRPjQiiTpedBpYE4Xz_LWoNOFDi0=.60f512b8-33f4-410f-8ec2-6ff34d62585c@github.com>
Message-ID: <6-rlDSiayVEXmUSxVc2PUxkP92a9mcmk_weMntHsw-k=.e2e0743b-f334-4c0b-9b29-6233eb5ded60@github.com>

On Fri, 27 Sep 2024 08:02:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I think there is a bad merge in `FileMapInfo::write_bitmap_region`.
> 
> The symptom on `runtime/cds` tests suggests we have have the overflow on `bitmap` buffer array we have just allocated, which suggests we miscalculated the size for it:
> 
> 
> #  Internal Error (/home/shade/trunks/shipilev-leyden/src/hotspot/share/nmt/mallocHeader.inline.hpp:107), pid=2332848, tid=2332849
> #  fatal error: NMT corruption: Block at 0x000078422d0c3120: footer canary broken at 0x000078422d0f8618 (buffer overflow?)
> 
> Stack: [0x0000784232100000,0x0000784232200000],  sp=0x00007842321fcfe0,  free space=1011k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x145e785]  MallocHeader* MallocHeader::resolve_checked_impl<void*, MallocHeader*>(void*)+0x145  (mallocHeader.inline.hpp:107)
> V  [libjvm.so+0x145d599]  MallocTracker::record_free_block(void*)+0x29  (mallocHeader.inline.hpp:113)
> V  [libjvm.so+0x15dc42a]  os::free(void*)+0x6a  (memTracker.hpp:94)
> V  [libjvm.so+0x64a487]  ArchiveBuilder::write_archive(FileMapInfo*, ArchiveHeapInfo*)+0x457  (archiveBuilder.cpp:1569)
> V  [libjvm.so+0x14d3ece]  MetaspaceShared::write_static_archive(ArchiveBuilder*, FileMapInfo*, ArchiveHeapInfo*)+0x4e  (metaspaceShared.cpp:1016)
> V  [libjvm.so+0x14d9066]  MetaspaceShared::preload_and_dump_impl(StaticArchiveBuilder&, JavaThread*)+0x5c6  (metaspaceShared.cpp:999)
> V  [libjvm.so+0x14d9217]  MetaspaceShared::preload_and_dump(JavaThread*)+0x87  (metaspaceShared.cpp:792)
> V  [libjvm.so+0x1a4cd3c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x122c  (threads.cpp:909)
> V  [libjvm.so+0x1078e78]  JNI_CreateJavaVM+0x58  (jni.cpp:3594)
> C  [libjli.so+0x4903]  JavaMain+0x93  (java.c:1494)
> C  [libjli.so+0x7f0d]  ThreadJavaMain+0xd  (java_md.c:633)
> 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` now passes

Hey @iklam :)

-------------

PR Comment: https://git.openjdk.org/leyden/pull/24#issuecomment-2378662823

From iklam at openjdk.org  Fri Sep 27 14:20:00 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 27 Sep 2024 14:20:00 GMT
Subject: RFR: FileMapInfo::write_bitmap_region bug after premain merge
In-Reply-To: <8GS1slv5sXiJzs1dRPjQiiTpedBpYE4Xz_LWoNOFDi0=.60f512b8-33f4-410f-8ec2-6ff34d62585c@github.com>
References: <8GS1slv5sXiJzs1dRPjQiiTpedBpYE4Xz_LWoNOFDi0=.60f512b8-33f4-410f-8ec2-6ff34d62585c@github.com>
Message-ID: <0Gh8MftRKATBcvLDxUQIrMDOfMLtBqtLStA3844Ohds=.1d7eaa1b-a0e7-441e-83b4-d803847da428@github.com>

On Fri, 27 Sep 2024 08:02:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I think there is a bad merge in `FileMapInfo::write_bitmap_region`.
> 
> The symptom on `runtime/cds` tests suggests we have have the overflow on `bitmap` buffer array we have just allocated, which suggests we miscalculated the size for it:
> 
> 
> #  Internal Error (/home/shade/trunks/shipilev-leyden/src/hotspot/share/nmt/mallocHeader.inline.hpp:107), pid=2332848, tid=2332849
> #  fatal error: NMT corruption: Block at 0x000078422d0c3120: footer canary broken at 0x000078422d0f8618 (buffer overflow?)
> 
> Stack: [0x0000784232100000,0x0000784232200000],  sp=0x00007842321fcfe0,  free space=1011k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x145e785]  MallocHeader* MallocHeader::resolve_checked_impl<void*, MallocHeader*>(void*)+0x145  (mallocHeader.inline.hpp:107)
> V  [libjvm.so+0x145d599]  MallocTracker::record_free_block(void*)+0x29  (mallocHeader.inline.hpp:113)
> V  [libjvm.so+0x15dc42a]  os::free(void*)+0x6a  (memTracker.hpp:94)
> V  [libjvm.so+0x64a487]  ArchiveBuilder::write_archive(FileMapInfo*, ArchiveHeapInfo*)+0x457  (archiveBuilder.cpp:1569)
> V  [libjvm.so+0x14d3ece]  MetaspaceShared::write_static_archive(ArchiveBuilder*, FileMapInfo*, ArchiveHeapInfo*)+0x4e  (metaspaceShared.cpp:1016)
> V  [libjvm.so+0x14d9066]  MetaspaceShared::preload_and_dump_impl(StaticArchiveBuilder&, JavaThread*)+0x5c6  (metaspaceShared.cpp:999)
> V  [libjvm.so+0x14d9217]  MetaspaceShared::preload_and_dump(JavaThread*)+0x87  (metaspaceShared.cpp:792)
> V  [libjvm.so+0x1a4cd3c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x122c  (threads.cpp:909)
> V  [libjvm.so+0x1078e78]  JNI_CreateJavaVM+0x58  (jni.cpp:3594)
> C  [libjli.so+0x4903]  JavaMain+0x93  (java.c:1494)
> C  [libjli.so+0x7f0d]  ThreadJavaMain+0xd  (java_md.c:633)
> 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` now passes

Marked as reviewed by iklam (Committer).

Sorry I fixed this in my repo but forgot to commit the change!

Thanks for fixing.

-------------

PR Review: https://git.openjdk.org/leyden/pull/24#pullrequestreview-2333871880
PR Comment: https://git.openjdk.org/leyden/pull/24#issuecomment-2379387073

From duke at openjdk.org  Fri Sep 27 14:20:00 2024
From: duke at openjdk.org (duke)
Date: Fri, 27 Sep 2024 14:20:00 GMT
Subject: RFR: FileMapInfo::write_bitmap_region bug after premain merge
In-Reply-To: <8GS1slv5sXiJzs1dRPjQiiTpedBpYE4Xz_LWoNOFDi0=.60f512b8-33f4-410f-8ec2-6ff34d62585c@github.com>
References: <8GS1slv5sXiJzs1dRPjQiiTpedBpYE4Xz_LWoNOFDi0=.60f512b8-33f4-410f-8ec2-6ff34d62585c@github.com>
Message-ID: <WunyFNh5aQdFqMCVKohks9QlAx3Y7n1aiJkn4uMaFf0=.ef448b91-3d03-4b78-bb04-abd9c66335a2@github.com>

On Fri, 27 Sep 2024 08:02:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I think there is a bad merge in `FileMapInfo::write_bitmap_region`.
> 
> The symptom on `runtime/cds` tests suggests we have have the overflow on `bitmap` buffer array we have just allocated, which suggests we miscalculated the size for it:
> 
> 
> #  Internal Error (/home/shade/trunks/shipilev-leyden/src/hotspot/share/nmt/mallocHeader.inline.hpp:107), pid=2332848, tid=2332849
> #  fatal error: NMT corruption: Block at 0x000078422d0c3120: footer canary broken at 0x000078422d0f8618 (buffer overflow?)
> 
> Stack: [0x0000784232100000,0x0000784232200000],  sp=0x00007842321fcfe0,  free space=1011k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x145e785]  MallocHeader* MallocHeader::resolve_checked_impl<void*, MallocHeader*>(void*)+0x145  (mallocHeader.inline.hpp:107)
> V  [libjvm.so+0x145d599]  MallocTracker::record_free_block(void*)+0x29  (mallocHeader.inline.hpp:113)
> V  [libjvm.so+0x15dc42a]  os::free(void*)+0x6a  (memTracker.hpp:94)
> V  [libjvm.so+0x64a487]  ArchiveBuilder::write_archive(FileMapInfo*, ArchiveHeapInfo*)+0x457  (archiveBuilder.cpp:1569)
> V  [libjvm.so+0x14d3ece]  MetaspaceShared::write_static_archive(ArchiveBuilder*, FileMapInfo*, ArchiveHeapInfo*)+0x4e  (metaspaceShared.cpp:1016)
> V  [libjvm.so+0x14d9066]  MetaspaceShared::preload_and_dump_impl(StaticArchiveBuilder&, JavaThread*)+0x5c6  (metaspaceShared.cpp:999)
> V  [libjvm.so+0x14d9217]  MetaspaceShared::preload_and_dump(JavaThread*)+0x87  (metaspaceShared.cpp:792)
> V  [libjvm.so+0x1a4cd3c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x122c  (threads.cpp:909)
> V  [libjvm.so+0x1078e78]  JNI_CreateJavaVM+0x58  (jni.cpp:3594)
> C  [libjli.so+0x4903]  JavaMain+0x93  (java.c:1494)
> C  [libjli.so+0x7f0d]  ThreadJavaMain+0xd  (java_md.c:633)
> 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` now passes

@iklam 
Your change (at version 0e3ce99b80a96a6140019b52c5b719508f0f2176) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/24#issuecomment-2379390622

From iklam at openjdk.org  Fri Sep 27 14:25:35 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 27 Sep 2024 14:25:35 GMT
Subject: git: openjdk/leyden: premain: FileMapInfo::write_bitmap_region bug
 after premain merge
Message-ID: <7bf81bd9-f087-4b80-a564-bc4f6a19c8c8@openjdk.org>

Changeset: 7b72b048
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: Ioi Lam <iklam at openjdk.org>
Date:      2024-09-27 14:23:51 +0000
URL:       https://git.openjdk.org/leyden/commit/7b72b048474091f123c055bd5b8d7fd7c00d19d4

FileMapInfo::write_bitmap_region bug after premain merge

Reviewed-by: iklam

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


From shade at openjdk.org  Fri Sep 27 14:26:53 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 27 Sep 2024 14:26:53 GMT
Subject: Integrated: FileMapInfo::write_bitmap_region bug after premain merge
In-Reply-To: <8GS1slv5sXiJzs1dRPjQiiTpedBpYE4Xz_LWoNOFDi0=.60f512b8-33f4-410f-8ec2-6ff34d62585c@github.com>
References: <8GS1slv5sXiJzs1dRPjQiiTpedBpYE4Xz_LWoNOFDi0=.60f512b8-33f4-410f-8ec2-6ff34d62585c@github.com>
Message-ID: <IwrUOHoBA-uaaHhznIGM8gcn3TYhDkIPIMG093y0ruY=.0091a0e4-48ed-4c10-9c00-82a9fb7a2eb7@github.com>

On Fri, 27 Sep 2024 08:02:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I think there is a bad merge in `FileMapInfo::write_bitmap_region`.
> 
> The symptom on `runtime/cds` tests suggests we have have the overflow on `bitmap` buffer array we have just allocated, which suggests we miscalculated the size for it:
> 
> 
> #  Internal Error (/home/shade/trunks/shipilev-leyden/src/hotspot/share/nmt/mallocHeader.inline.hpp:107), pid=2332848, tid=2332849
> #  fatal error: NMT corruption: Block at 0x000078422d0c3120: footer canary broken at 0x000078422d0f8618 (buffer overflow?)
> 
> Stack: [0x0000784232100000,0x0000784232200000],  sp=0x00007842321fcfe0,  free space=1011k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x145e785]  MallocHeader* MallocHeader::resolve_checked_impl<void*, MallocHeader*>(void*)+0x145  (mallocHeader.inline.hpp:107)
> V  [libjvm.so+0x145d599]  MallocTracker::record_free_block(void*)+0x29  (mallocHeader.inline.hpp:113)
> V  [libjvm.so+0x15dc42a]  os::free(void*)+0x6a  (memTracker.hpp:94)
> V  [libjvm.so+0x64a487]  ArchiveBuilder::write_archive(FileMapInfo*, ArchiveHeapInfo*)+0x457  (archiveBuilder.cpp:1569)
> V  [libjvm.so+0x14d3ece]  MetaspaceShared::write_static_archive(ArchiveBuilder*, FileMapInfo*, ArchiveHeapInfo*)+0x4e  (metaspaceShared.cpp:1016)
> V  [libjvm.so+0x14d9066]  MetaspaceShared::preload_and_dump_impl(StaticArchiveBuilder&, JavaThread*)+0x5c6  (metaspaceShared.cpp:999)
> V  [libjvm.so+0x14d9217]  MetaspaceShared::preload_and_dump(JavaThread*)+0x87  (metaspaceShared.cpp:792)
> V  [libjvm.so+0x1a4cd3c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x122c  (threads.cpp:909)
> V  [libjvm.so+0x1078e78]  JNI_CreateJavaVM+0x58  (jni.cpp:3594)
> C  [libjli.so+0x4903]  JavaMain+0x93  (java.c:1494)
> C  [libjli.so+0x7f0d]  ThreadJavaMain+0xd  (java_md.c:633)
> 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` now passes

This pull request has now been integrated.

Changeset: 7b72b048
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/leyden/commit/7b72b048474091f123c055bd5b8d7fd7c00d19d4
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

FileMapInfo::write_bitmap_region bug after premain merge

Reviewed-by: iklam

-------------

PR: https://git.openjdk.org/leyden/pull/24

From shade at openjdk.org  Fri Sep 27 18:52:31 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 27 Sep 2024 18:52:31 GMT
Subject: RFR: Enable 1-step workflow with Shenandoah GC [v3]
In-Reply-To: <o-jjFUp6XKu9fFF9_BDQ6Gf2xi4I4I5cUJlvq_evKrY=.8419a68c-ae5f-43f0-b332-1d421472d9c7@github.com>
References: <o-jjFUp6XKu9fFF9_BDQ6Gf2xi4I4I5cUJlvq_evKrY=.8419a68c-ae5f-43f0-b332-1d421472d9c7@github.com>
Message-ID: <_2MG3IbTVKtNmKauhDfYWQrIJt3Xlqjvpes26c8ndu0=.56042062-1ead-45ab-b33e-f64889ff0a52@github.com>

> WIP, includes upstream [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650).
> 
> I checked this works well:
> 
> 
> #!/bin/bash
> make images
> J=build/macosx-aarch64-server-fastdebug/images/jdk/bin/java
> rm -fv JavacBenchApp.cds*
> $J -XX:+UseShenandoahGC -XX:CacheDataStore=JavacBenchApp.cds -cp JavacBenchApp.jar JavacBenchApp 50
> $J -XX:+UseShenandoahGC -XX:CacheDataStore=JavacBenchApp.cds -cp JavacBenchApp.jar JavacBenchApp 50
> 
> 
> I'll look around what other tests I need to run.

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Make sure LeydenGCFlags passes when some GCs are not configured
 - Shenandoah support

-------------

Changes: https://git.openjdk.org/leyden/pull/8/files
  Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=8&range=02
  Stats: 73 lines in 6 files changed: 49 ins; 3 del; 21 mod
  Patch: https://git.openjdk.org/leyden/pull/8.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/8/head:pull/8

PR: https://git.openjdk.org/leyden/pull/8

From shade at openjdk.org  Fri Sep 27 19:00:53 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 27 Sep 2024 19:00:53 GMT
Subject: RFR: Enable 1-step workflow with Shenandoah GC [v3]
In-Reply-To: <_2MG3IbTVKtNmKauhDfYWQrIJt3Xlqjvpes26c8ndu0=.56042062-1ead-45ab-b33e-f64889ff0a52@github.com>
References: <o-jjFUp6XKu9fFF9_BDQ6Gf2xi4I4I5cUJlvq_evKrY=.8419a68c-ae5f-43f0-b332-1d421472d9c7@github.com>
 <_2MG3IbTVKtNmKauhDfYWQrIJt3Xlqjvpes26c8ndu0=.56042062-1ead-45ab-b33e-f64889ff0a52@github.com>
Message-ID: <tjtZdz6ZLtzXDdTR_r-G4h9gWi9Mdezy7xU8B27LxTk=.ac9f806b-9980-4a17-a589-8782970c66ec@github.com>

On Fri, 27 Sep 2024 18:52:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> WIP, includes upstream [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650).
>> 
>> I checked this works well:
>> 
>> 
>> #!/bin/bash
>> make images
>> J=build/macosx-aarch64-server-fastdebug/images/jdk/bin/java
>> rm -fv JavacBenchApp.cds*
>> $J -XX:+UseShenandoahGC -XX:CacheDataStore=JavacBenchApp.cds -cp JavacBenchApp.jar JavacBenchApp 50
>> $J -XX:+UseShenandoahGC -XX:CacheDataStore=JavacBenchApp.cds -cp JavacBenchApp.jar JavacBenchApp 50
>> 
>> 
>> I'll look around what other tests I need to run.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Make sure LeydenGCFlags passes when some GCs are not configured
>  - Shenandoah support

Now waiting for https://github.com/openjdk/jdk/pull/21152 to arrive, so that we don't have a merge problem later.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/8#issuecomment-2379882153

From duke at openjdk.org  Sat Sep 28 00:48:42 2024
From: duke at openjdk.org (duke)
Date: Sat, 28 Sep 2024 00:48:42 GMT
Subject: git: openjdk/leyden: hermetic-java-runtime: 89 new changesets
Message-ID: <350cc779-b906-478d-9d19-7cb35bf8004d@openjdk.org>

Changeset: c6f1d5f3
Branch: hermetic-java-runtime
Author:    Francisco Ferrari Bihurriet <fferrari at openjdk.org>
Date:      2024-09-23 17:45:38 +0000
URL:       https://git.openjdk.org/leyden/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab

8319332: Security properties files inclusion

Co-authored-by: Francisco Ferrari Bihurriet <fferrari at openjdk.org>
Co-authored-by: Martin Balao <mbalao at openjdk.org>
Reviewed-by: weijun, mullan, kdriver

! src/java.base/share/classes/java/security/Security.java
! src/java.base/share/classes/sun/security/util/PropertyExpander.java
! src/java.base/share/conf/security/java.security
! test/jdk/java/security/Security/ConfigFileTest.java
- test/jdk/java/security/Security/override.props
! test/jdk/java/security/Security/signedfirst/DynStatic.java

Changeset: 833ff299
Branch: hermetic-java-runtime
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-09-23 18:25:12 +0000
URL:       https://git.openjdk.org/leyden/commit/833ff29983e0d433ccd4c7e946b15e42045faeaa

8340461: Amend description for logArea

Reviewed-by: azvegint, prr

! test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

Changeset: 8dcf7b8f
Branch: hermetic-java-runtime
Author:    Phil Race <prr at openjdk.org>
Date:      2024-09-23 18:26:52 +0000
URL:       https://git.openjdk.org/leyden/commit/8dcf7b8fa7b17bf34c62c561c6ed78e8080df1ff

8340411: open source several 2D imaging tests

Reviewed-by: azvegint

+ test/jdk/sun/awt/image/BytePackedRaster/DitherTest.java
+ test/jdk/sun/awt/image/BytePackedRaster/MultiOp.java
+ test/jdk/sun/awt/image/ImageRepresentation/ByteBinaryBitmask.java
+ test/jdk/sun/awt/image/ImageRepresentation/CustomSourceCM.java

Changeset: e97f0fe1
Branch: hermetic-java-runtime
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-09-23 18:31:31 +0000
URL:       https://git.openjdk.org/leyden/commit/e97f0fe1b4046bfcc40e85ba1bee4f4c40053300

8340365: Position the first window of a window list

Reviewed-by: azvegint, prr

! test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

Changeset: cd796e0a
Branch: hermetic-java-runtime
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2024-09-24 00:13:49 +0000
URL:       https://git.openjdk.org/leyden/commit/cd796e0aef321d46c96f79dc5446d095b8a30e60

8338918: Remove non translated file name from WinResources resource bundle

Reviewed-by: jlu, almatvee

! src/jdk.jpackage/share/classes/jdk/jpackage/internal/I18N.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties
= src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResourcesNoL10N.properties
= src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResourcesNoL10N_de.properties
= src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResourcesNoL10N_ja.properties
= src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResourcesNoL10N_zh_CN.properties
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties

Changeset: c8ae8480
Branch: hermetic-java-runtime
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-09-24 00:37:21 +0000
URL:       https://git.openjdk.org/leyden/commit/c8ae8480496d56a8e51b9f5a6df50c70a429672f

8340707: ProblemList applications/ctw/modules/java_base.java due to JDK-8340683

Reviewed-by: darcy

! test/hotspot/jtreg/ProblemList.txt

Changeset: 40cde003
Branch: hermetic-java-runtime
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-24 01:47:57 +0000
URL:       https://git.openjdk.org/leyden/commit/40cde003e8061a0eb6b0214d5a44325c3d55cdc6

8340114: Remove outdated SelectVersion() function from the launcher and update the code comments explaining the code flow

Reviewed-by: dholmes, alanb

! src/java.base/macosx/native/libjli/java_md_macosx.m
! src/java.base/share/native/libjli/emessages.h
! src/java.base/share/native/libjli/java.c
! src/java.base/share/native/libjli/java.h
! src/java.base/share/native/libjli/manifest_info.h
! src/java.base/share/native/libjli/parse_manifest.c
! src/java.base/unix/native/libjli/java_md.c
- test/jdk/tools/launcher/MultipleJRERemoved.java

Changeset: 3411f9df
Branch: hermetic-java-runtime
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-24 02:08:06 +0000
URL:       https://git.openjdk.org/leyden/commit/3411f9dff79c2e7cb7ce8ebf036f8b3fd9bb647d

8339995: Open source several AWT focus tests - series 6

Reviewed-by: prr

! test/jdk/ProblemList.txt
+ test/jdk/java/awt/Focus/ConsumedKeyEventTest.java
+ test/jdk/java/awt/Focus/EmptyWindowKeyTest.java
+ test/jdk/java/awt/Focus/InactiveFocusRace.java
+ test/jdk/java/awt/Focus/InitialPrintDlgFocusTest.java

Changeset: 865d99f6
Branch: hermetic-java-runtime
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-24 02:08:20 +0000
URL:       https://git.openjdk.org/leyden/commit/865d99f63475799b9a0503a3dcc21a7534b014d1

8340596: Remove dead code from RequiresSetenv function in java.base/unix/native/libjli/java_md.c

Reviewed-by: dholmes

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

Changeset: 6c91a16f
Branch: hermetic-java-runtime
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-24 02:09:42 +0000
URL:       https://git.openjdk.org/leyden/commit/6c91a16f16cbeb1bb0a79459e7db1fd9f576e743

8340367: Opensource few AWT image tests

Reviewed-by: prr

+ test/jdk/java/awt/image/BufferedImage/GrayAATextTest.java
+ test/jdk/java/awt/image/GrayAlpha.java
+ test/jdk/java/awt/image/ImageOffsetTest.java
+ test/jdk/java/awt/image/TransformImage.java
= test/jdk/java/awt/image/duke.gif

Changeset: 4098acc2
Branch: hermetic-java-runtime
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2024-09-24 05:35:12 +0000
URL:       https://git.openjdk.org/leyden/commit/4098acc200e608369ac1631dcc8513ea797bd59e

8340146: ZGC: TestAllocateHeapAt.java should not run with UseLargePages

Reviewed-by: tschatzl, stefank

! test/hotspot/jtreg/gc/x/TestAllocateHeapAt.java
! test/hotspot/jtreg/gc/z/TestAllocateHeapAt.java
! test/jtreg-ext/requires/VMProps.java

Changeset: 1dd60b62
Branch: hermetic-java-runtime
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-09-24 06:47:20 +0000
URL:       https://git.openjdk.org/leyden/commit/1dd60b62e384090b13a08d2afa62e49ef52bc46c

8323688: C2: Fix UB of jlong overflow in PhaseIdealLoop::is_counted_loop()

Reviewed-by: thartmann, kvn

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

Changeset: 88801cae
Branch: hermetic-java-runtime
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2024-09-24 07:09:10 +0000
URL:       https://git.openjdk.org/leyden/commit/88801caef6ccdc5ba9ade2af830f3b3cd96e1467

8340590: RISC-V: C2: Small improvement to vector gather load and scatter store

Reviewed-by: fyang, dzhang

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

Changeset: 9176f681
Branch: hermetic-java-runtime
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-09-24 07:22:27 +0000
URL:       https://git.openjdk.org/leyden/commit/9176f6810ef914579b8ca8e3bc20a0fdf3a934c8

8340623: Remove outdated PROCESSOR_ARCHITECTURE_IA64 from Windows coding

Reviewed-by: alanb, dholmes

! src/java.base/windows/native/libjava/java_props_md.c

Changeset: e60e8821
Branch: hermetic-java-runtime
Author:    Afshin Zafari <azafari at openjdk.org>
Date:      2024-09-24 07:56:14 +0000
URL:       https://git.openjdk.org/leyden/commit/e60e8821568a74269340417fece2acb71f633098

8335167: Test runtime/Thread/TestAlwaysPreTouchStacks.java failed with Expected a higher ratio between stack committed and reserved

Reviewed-by: stuefe, dholmes, gziemski

! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/runtime/Thread/TestAlwaysPreTouchStacks.java

Changeset: 44024826
Branch: hermetic-java-runtime
Author:    Yudi Zheng <yzheng at openjdk.org>
Date:      2024-09-24 08:25:06 +0000
URL:       https://git.openjdk.org/leyden/commit/44024826e52373d1613ec366e3f5a9d5bbaefa41

8340585: [JVMCI] compiler/unsafe/UnsafeGetStableArrayElement.java fails with -XX:-UseCompressedClassPointers

Reviewed-by: dnsimon

! test/hotspot/jtreg/compiler/unsafe/UnsafeGetStableArrayElement.java

Changeset: 4cd8c75a
Branch: hermetic-java-runtime
Author:    Tomas Zezula <tzezula at openjdk.org>
Committer: Doug Simon <dnsimon at openjdk.org>
Date:      2024-09-24 10:19:38 +0000
URL:       https://git.openjdk.org/leyden/commit/4cd8c75a55163be33917b1fba9f360ea816f3aa9

8340398: [JVMCI] Unintuitive behavior of UseJVMCICompiler option

Reviewed-by: dnsimon

! src/hotspot/share/jvmci/jvmci_globals.cpp
! src/hotspot/share/jvmci/jvmci_globals.hpp
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJVMCICompilerConfig.java

Changeset: 3e673d9e
Branch: hermetic-java-runtime
Author:    Pavel Rappo <prappo at openjdk.org>
Date:      2024-09-24 10:48:35 +0000
URL:       https://git.openjdk.org/leyden/commit/3e673d9e46ddb464263ff76f385ca5bf98a0b19d

8340680: Fix typos in javax.lang.model.SourceVersion

Reviewed-by: darcy, iris

! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java

Changeset: e1c4d303
Branch: hermetic-java-runtime
Author:    Kuai Wei <kuaiwei.kw at alibaba-inc.com>
Date:      2024-09-24 11:08:36 +0000
URL:       https://git.openjdk.org/leyden/commit/e1c4d3039f6b5106ce3f65d50f607eacc2a8d168

8339299: C1 will miss type profile when inline final method

Reviewed-by: lmesnik, vlivanov

! src/hotspot/share/c1/c1_LIR.hpp
+ test/hotspot/jtreg/compiler/cha/TypeProfileFinalMethod.java

Changeset: 49d15edd
Branch: hermetic-java-runtime
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2024-09-24 12:43:00 +0000
URL:       https://git.openjdk.org/leyden/commit/49d15edd31c863faf3722af1bae8b50662ecf71f

8340657: [PPC64] SA determines wrong unextendedSP

Reviewed-by: ysuenaga, mbaesken

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java

Changeset: 3c97d243
Branch: hermetic-java-runtime
Author:    George Adams <gdams at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
Date:      2024-09-24 12:50:33 +0000
URL:       https://git.openjdk.org/leyden/commit/3c97d2437d34d2db47f3607fbb95ac3b8e2ec60b

8340383: VM issues warning failure to find kernel32.dll on Windows nanoserver

Reviewed-by: dholmes, jwaters

! src/hotspot/os/windows/os_windows.cpp

Changeset: 279086d4
Branch: hermetic-java-runtime
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2024-09-24 13:16:43 +0000
URL:       https://git.openjdk.org/leyden/commit/279086d4ce7e05972e099022e8045f39680dd4e8

8340408: Shenandoah: Remove redundant task stats printing code in ShenandoahTaskQueue

Reviewed-by: shade, wkemper

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.cpp
! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp

Changeset: caa751c5
Branch: hermetic-java-runtime
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-24 14:28:05 +0000
URL:       https://git.openjdk.org/leyden/commit/caa751c561f55bc59a6195a947d7b75515b5d2c0

8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)

Reviewed-by: asotona, redestad

! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
! src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java
! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java
! test/jdk/jdk/classfile/ConstantDescSymbolsTest.java
! test/jdk/jdk/classfile/UtilTest.java
+ test/jdk/jdk/classfile/java.base/jdk/internal/classfile/impl/UtilAccess.java
+ test/micro/org/openjdk/bench/jdk/classfile/ConstantPoolBuildingClassEntry.java

Changeset: 85aed877
Branch: hermetic-java-runtime
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
Date:      2024-09-24 14:40:38 +0000
URL:       https://git.openjdk.org/leyden/commit/85aed877960ef86b483b76ce4fcf95602ae2b924

8338405: JFR: Use FILE type for dcmds

Reviewed-by: egahlin, lmesnik

! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/AbstractDCmd.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/ArgumentParser.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdDump.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStop.java

Changeset: 2669e22b
Branch: hermetic-java-runtime
Author:    Andrew Dinn <adinn at openjdk.org>
Date:      2024-09-24 14:51:28 +0000
URL:       https://git.openjdk.org/leyden/commit/2669e22b76c99c1e41a324099154b561e0433b56

8340793: Fix client builds after JDK-8337987

Reviewed-by: shade, fyang

! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/arm/sharedRuntime_arm.cpp
! src/hotspot/cpu/s390/sharedRuntime_s390.cpp

Changeset: 212e3293
Branch: hermetic-java-runtime
Author:    vamsi-parasa <srinivas.vamsi.parasa at intel.com>
Date:      2024-09-24 15:11:13 +0000
URL:       https://git.openjdk.org/leyden/commit/212e32931cafe446d94219d6c3ffd92261984dff

8338694: x86_64 intrinsic for tanh using libm

Reviewed-by: kvn, jbhateja, sgibbons, sviswanathan

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.hpp
+ src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp
! src/hotspot/cpu/x86/templateInterpreterGenerator_x86_32.cpp
! src/hotspot/cpu/x86/templateInterpreterGenerator_x86_64.cpp
! src/hotspot/share/c1/c1_Compiler.cpp
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/classfile/vmIntrinsics.cpp
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/interpreter/abstractInterpreter.cpp
! src/hotspot/share/interpreter/abstractInterpreter.hpp
! src/hotspot/share/interpreter/templateInterpreterGenerator.cpp
! src/hotspot/share/interpreter/zero/zeroInterpreterGenerator.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/runtime/stubRoutines.cpp
! src/hotspot/share/runtime/stubRoutines.hpp
! src/java.base/share/classes/java/lang/Math.java
! test/jdk/java/lang/Math/HyperbolicTests.java

Changeset: 90c2c0b4
Branch: hermetic-java-runtime
Author:    Phil Race <prr at openjdk.org>
Date:      2024-09-24 18:07:33 +0000
URL:       https://git.openjdk.org/leyden/commit/90c2c0b4ad4ee7d2ea149aea771cf81bd666b1dc

8340143: Open source several Java2D rendering loop tests.

Reviewed-by: psadhukhan

+ test/jdk/sun/java2d/loops/ARGBBgToRGB.java
+ test/jdk/sun/java2d/loops/CopyNegative.java
+ test/jdk/sun/java2d/loops/DitheredSolidFill.java
+ test/jdk/sun/java2d/loops/OffsetCalculationTest.java
+ test/jdk/sun/java2d/loops/XORClearRect.java

Changeset: 8c08c43a
Branch: hermetic-java-runtime
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
Date:      2024-09-24 18:56:22 +0000
URL:       https://git.openjdk.org/leyden/commit/8c08c43a34b7a237c0281ef58594af4f263ba3ca

8340433: Open source closed choice tests #3

Reviewed-by: honkar, prr

+ test/jdk/java/awt/Choice/ChoicePosTest.java
+ test/jdk/java/awt/Choice/DeadlockTest.java
+ test/jdk/java/awt/Choice/SetFontTest.java

Changeset: e3d80f1e
Branch: hermetic-java-runtime
Author:    Artur Barashev <artur.barashev at oracle.com>
Committer: Sean Mullan <mullan at openjdk.org>
Date:      2024-09-24 18:57:58 +0000
URL:       https://git.openjdk.org/leyden/commit/e3d80f1e1e8b5d503f13b8037172e3dac29e27ad

8340670: Policy.UNSUPPORTED_EMPTY_COLLECTION.isReadOnly does not return true

Reviewed-by: mullan

! src/java.base/share/classes/java/security/Policy.java

Changeset: b639661e
Branch: hermetic-java-runtime
Author:    George Adams <gdams at openjdk.org>
Date:      2024-09-24 19:35:59 +0000
URL:       https://git.openjdk.org/leyden/commit/b639661e797fb52ce32ce397a153c886fdc40f53

8340804: doc/building.md update Xcode instructions to note that full install is required

Reviewed-by: erikj, jwaters

! doc/building.html
! doc/building.md

Changeset: 0b8c9f6d
Branch: hermetic-java-runtime
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2024-09-24 20:09:40 +0000
URL:       https://git.openjdk.org/leyden/commit/0b8c9f6d2397dcb480dc5ae109607d86f2b15619

8338525: Leading and trailing code blocks by indentation

Reviewed-by: hannesw, prappo

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java
! test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdownCodeBlocks.java
! test/langtools/tools/javac/doctree/DocCommentTester.java
! test/langtools/tools/javac/doctree/MarkdownTest.java

Changeset: c0fcb258
Branch: hermetic-java-runtime
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-09-25 01:45:04 +0000
URL:       https://git.openjdk.org/leyden/commit/c0fcb258bbd02892267970dc4bc082dc7761f074

8340717: Remove unused function declarations from java.c/java.h of the launcher

Reviewed-by: alanb, dholmes, shade, jwaters

! src/java.base/share/native/libjli/java.c
! src/java.base/share/native/libjli/java.h

Changeset: a37bb2e0
Branch: hermetic-java-runtime
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2024-09-25 02:29:06 +0000
URL:       https://git.openjdk.org/leyden/commit/a37bb2e0372a7c074c88d31824fc418a47f63405

8340643: RISC-V: Small refactoring for sub/subw macro-assembler routines

Reviewed-by: fyang, luhenry

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

Changeset: 9bcc7b66
Branch: hermetic-java-runtime
Author:    Shaojin Wen <swen at openjdk.org>
Date:      2024-09-25 02:30:46 +0000
URL:       https://git.openjdk.org/leyden/commit/9bcc7b66de6495d3da8fc7f30a2a88187dbe847d

8340708: Optimize StackMapGenerator::processMethod

Reviewed-by: liach

! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java

Changeset: 2d38af61
Branch: hermetic-java-runtime
Author:    Shaojin Wen <swen at openjdk.org>
Date:      2024-09-25 02:32:29 +0000
URL:       https://git.openjdk.org/leyden/commit/2d38af61e4133ca98d5a98b3cfb6a6dde2877026

8340587: Optimize StackMapGenerator$Frame::checkAssignableTo

Reviewed-by: liach

! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java

Changeset: 2e0554a6
Branch: hermetic-java-runtime
Author:    Shaojin Wen <swen at openjdk.org>
Date:      2024-09-25 02:35:41 +0000
URL:       https://git.openjdk.org/leyden/commit/2e0554a69548dae6e8ce9eec48c82e08dd3c1ffa

8340710: Optimize DirectClassBuilder::build

Reviewed-by: liach

! src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectClassBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java

Changeset: b1f8d2ea
Branch: hermetic-java-runtime
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-25 03:07:45 +0000
URL:       https://git.openjdk.org/leyden/commit/b1f8d2ea76322a89eea84851a1e791f52c31261b

8339935: Open source several AWT focus tests - series 5

Reviewed-by: prr

+ test/jdk/java/awt/Focus/DeiconifyTest.java
+ test/jdk/java/awt/Focus/HiddenTraversalTest.java
+ test/jdk/java/awt/Focus/LightweightPopupTest.java
+ test/jdk/java/awt/Focus/ProxiedWindowHideTest.java

Changeset: 97a3933f
Branch: hermetic-java-runtime
Author:    Robbin Ehn <rehn at openjdk.org>
Date:      2024-09-25 08:11:00 +0000
URL:       https://git.openjdk.org/leyden/commit/97a3933f1be2cabfc574689bb60618fe6fa3a8a4

8339771: RISC-V: Reduce icache flushes

Reviewed-by: fyang, mli, luhenry

! src/hotspot/cpu/riscv/assembler_riscv.hpp
! src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.cpp
! src/hotspot/cpu/riscv/globals_riscv.hpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp
! src/hotspot/cpu/riscv/relocInfo_riscv.cpp
! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp
! src/hotspot/cpu/riscv/vm_version_riscv.hpp
! src/hotspot/os_cpu/linux_riscv/orderAccess_linux_riscv.hpp
! src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp

Changeset: 9806d213
Branch: hermetic-java-runtime
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-09-25 08:13:25 +0000
URL:       https://git.openjdk.org/leyden/commit/9806d2139cb5994effdee3f7bc6b23eb81858ed3

8340808: RISC-V: Client build fails after JDK-8339738

Reviewed-by: fyang

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

Changeset: 1b9898a4
Branch: hermetic-java-runtime
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2024-09-25 09:26:06 +0000
URL:       https://git.openjdk.org/leyden/commit/1b9898a44fd3f8159a7184053ef50cba55419d6e

8340843: [PPC64/s390x] Error: ShouldNotReachHere() in TemplateInterpreterGenerator::generate_math_entry after 8338694

Reviewed-by: mbaesken, amitkumar

! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
! src/hotspot/cpu/s390/templateInterpreterGenerator_s390.cpp

Changeset: 120463dc
Branch: hermetic-java-runtime
Author:    Hannes Walln?fer <hannesw at openjdk.org>
Date:      2024-09-25 12:15:07 +0000
URL:       https://git.openjdk.org/leyden/commit/120463dc90d717bffb2bd0d5e6b1ea707f5d1b42

8339541: CSS rule is not specific enough

Reviewed-by: jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/stylesheet.css

Changeset: d8790aa0
Branch: hermetic-java-runtime
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-09-25 13:04:46 +0000
URL:       https://git.openjdk.org/leyden/commit/d8790aa0489fe49b499535c31cdfb691003792ff

8340885: Desugar ZipCoder.Comparison

Reviewed-by: lancea, eirbjo

! src/java.base/share/classes/java/util/zip/ZipCoder.java
! src/java.base/share/classes/java/util/zip/ZipFile.java

Changeset: 083b9808
Branch: hermetic-java-runtime
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2024-09-25 13:12:47 +0000
URL:       https://git.openjdk.org/leyden/commit/083b98083136933fc51499181f85ca30a77da9e1

8340568: Incorrect escaping of single quotes when pretty-printing character literals

Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java
+ test/langtools/tools/javac/tree/PrettyCharLiteral.java

Changeset: fb703258
Branch: hermetic-java-runtime
Author:    Leonov Kirill <91743110+kirleo2 at users.noreply.github.com>
Date:      2024-09-25 13:18:25 +0000
URL:       https://git.openjdk.org/leyden/commit/fb703258774ca14a6a239fc6d47a37e021e6036a

8338583: NMT: Malloc overhead is calculated incorrectly

Reviewed-by: azafari, yan, gziemski

! src/hotspot/share/nmt/mallocHeader.hpp
! src/hotspot/share/nmt/mallocTracker.hpp
! src/hotspot/share/nmt/memTracker.hpp

Changeset: 0474f020
Branch: hermetic-java-runtime
Author:    George Adams <gdams at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
Date:      2024-09-25 16:25:23 +0000
URL:       https://git.openjdk.org/leyden/commit/0474f020bf276c761f46bc8ba0873ed90a8fd19b

8340815: Add SECURITY.md file

Reviewed-by: mr, jwaters, erikj

+ SECURITY.md

Changeset: 81b5f097
Branch: hermetic-java-runtime
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-09-25 16:36:28 +0000
URL:       https://git.openjdk.org/leyden/commit/81b5f0974903accc738c07cdf7be09fa6ea8fbdd

8340946: Add vmTestbase/gc/memory/Nio/Nio.java and java/nio/Buffer/LimitDirectMemory.java to problem list

Reviewed-by: liach, dcubed, alanb

! test/hotspot/jtreg/ProblemList.txt
! test/jdk/ProblemList.txt

Changeset: 0e0b0b0d
Branch: hermetic-java-runtime
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Date:      2024-09-25 16:36:44 +0000
URL:       https://git.openjdk.org/leyden/commit/0e0b0b0d2626cda032f1500e64f6729554e47038

8340684: Reading from an input stream backed by a closed ZipFile has no test coverage

Reviewed-by: lancea

+ test/jdk/java/util/zip/ZipFile/ReadAfterClose.java

Changeset: f7bc9ba5
Branch: hermetic-java-runtime
Author:    Alexander Zuev <kizune at openjdk.org>
Date:      2024-09-25 16:46:49 +0000
URL:       https://git.openjdk.org/leyden/commit/f7bc9ba552cf913eef2131b964c48f1b4b55131c

8340228: Open source couple more miscellaneous AWT tests

Reviewed-by: prr

+ test/jdk/java/awt/Desktop/EditAndPrintTest/EditAndPrintTest.java
+ test/jdk/java/awt/TextField/GetTextTest/GetTextTest.java
+ test/jdk/java/awt/TextField/SetEchoCharTest3/SetEchoCharTest3.java

Changeset: 1b2d40ad
Branch: hermetic-java-runtime
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2024-09-25 17:19:02 +0000
URL:       https://git.openjdk.org/leyden/commit/1b2d40addfc5e32229418d29ae90fb440720479e

8340956: ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all

Reviewed-by: liach, alanb, darcy, dfuchs

! test/jdk/ProblemList.txt

Changeset: df1959fd
Branch: hermetic-java-runtime
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-25 18:29:30 +0000
URL:       https://git.openjdk.org/leyden/commit/df1959fd7a57f11839d58858bab4ea61f5b2bb8d

8340838: Clean up MutableCallSite to use explicit release fence instead of AtomicInteger

Reviewed-by: jrose, redestad, shade

! src/java.base/share/classes/java/lang/invoke/MutableCallSite.java

Changeset: 84751cbf
Branch: hermetic-java-runtime
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-25 18:31:24 +0000
URL:       https://git.openjdk.org/leyden/commit/84751cbfddf69bd9ed6bc5c39f8e056009440331

8340831: Simplify simple validation for class definition in MethodHandles.Lookup

Reviewed-by: redestad

! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/jdk/internal/misc/VM.java

Changeset: 8f756196
Branch: hermetic-java-runtime
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2024-09-25 18:51:16 +0000
URL:       https://git.openjdk.org/leyden/commit/8f756196b430af67a8e31a13811a183d52df8497

8340864: Remove unused lines related to vmClasses

Reviewed-by: shade, kvn

! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/classfile/vmClasses.cpp
! src/hotspot/share/classfile/vmClasses.hpp

Changeset: 66f16398
Branch: hermetic-java-runtime
Author:    Alisen Chung <achung at openjdk.org>
Date:      2024-09-26 01:16:13 +0000
URL:       https://git.openjdk.org/leyden/commit/66f1639846645f1d3b4096ef6d62f2b301cf7ed2

8339271: giflib attribution correction

Reviewed-by: dnguyen, prr

! src/java.desktop/share/legal/giflib.md

Changeset: 47c10694
Branch: hermetic-java-runtime
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2024-09-26 06:03:29 +0000
URL:       https://git.openjdk.org/leyden/commit/47c10694c66bc131c8a5e1572340415b8daaba08

8340812: LambdaForm customization via MethodHandle::updateForm is not thread safe

Reviewed-by: liach, shade, jvernee

! src/java.base/share/classes/java/lang/invoke/MethodHandle.java
+ test/jdk/java/lang/invoke/TestLambdaFormCustomization.java

Changeset: 8c8f0d85
Branch: hermetic-java-runtime
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-09-26 06:34:18 +0000
URL:       https://git.openjdk.org/leyden/commit/8c8f0d85ce30e45c34d4b096f7f1430cd9e7fd70

8339260: Move rarely used constants out of ClassFile

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
! src/java.base/share/classes/java/lang/classfile/ClassFile.java
! src/java.base/share/classes/java/lang/classfile/Opcode.java
! src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
! src/java.base/share/classes/java/lang/classfile/attribute/CharacterRangeInfo.java
! src/java.base/share/classes/java/lang/classfile/attribute/StackMapFrameInfo.java
! src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
! src/java.base/share/classes/java/lang/classfile/instruction/CharacterRange.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectClassBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java
! src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java
! src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java
! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
! src/java.base/share/classes/jdk/internal/classfile/impl/TargetInfoImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerificationBytecodes.java
! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/ConstantWriter.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMapWriter.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StringSharingPlugin.java
! test/jdk/jdk/classfile/LimitsTest.java
! test/jdk/jdk/classfile/StackMapsTest.java
! test/jdk/jdk/classfile/VerifierSelfTest.java
! test/jdk/jdk/classfile/helpers/ClassRecord.java

Changeset: 10da2c21
Branch: hermetic-java-runtime
Author:    Johan Sj?len <jsjolen at openjdk.org>
Date:      2024-09-26 08:47:32 +0000
URL:       https://git.openjdk.org/leyden/commit/10da2c21a19affe93a3f5d67a70db5d9cd37181c

8340923: The class LogSelection copies uninitialized memory

Reviewed-by: mbaesken, jwaters, stefank

! src/hotspot/share/logging/logSelection.cpp

Changeset: e2626db2
Branch: hermetic-java-runtime
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-09-26 11:34:30 +0000
URL:       https://git.openjdk.org/leyden/commit/e2626db2f00d0cc9f3ff8ea374a1ccc89373e398

8340899: Remove wildcard bound in PositionWindows.positionTestWindows

Reviewed-by: azvegint, prr

! test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

Changeset: 3762ec39
Branch: hermetic-java-runtime
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-09-26 11:36:42 +0000
URL:       https://git.openjdk.org/leyden/commit/3762ec3978bfe9910929ab22aaf238e9f4c84630

8340466: Add description for PassFailJFrame constructors

Reviewed-by: prr, honkar

! test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

Changeset: 777c20cb
Branch: hermetic-java-runtime
Author:    Lutz Schmidt <lucy at openjdk.org>
Date:      2024-09-26 11:45:09 +0000
URL:       https://git.openjdk.org/leyden/commit/777c20cb14010b6726834246ae4c61bc4ccb3f9b

8339542: compiler/codecache/CheckSegmentedCodeCache.java fails

Reviewed-by: mdoerr, shade

! test/hotspot/jtreg/compiler/codecache/CheckSegmentedCodeCache.java

Changeset: 47fcf5a3
Branch: hermetic-java-runtime
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
Date:      2024-09-26 12:33:23 +0000
URL:       https://git.openjdk.org/leyden/commit/47fcf5a3b0796ffeb6407be961ceb552ca2a40f8

8340687: Open source closed frame tests #1

Reviewed-by: aivanov

+ test/jdk/java/awt/Frame/DefaultFrameIconTest.java
+ test/jdk/java/awt/Frame/DisposeTest.java
+ test/jdk/java/awt/Frame/FramePaintTest.java
+ test/jdk/java/awt/Frame/MenuCrash.java

Changeset: 95d3e9d1
Branch: hermetic-java-runtime
Author:    Fernando Guallini <fguallini at openjdk.org>
Committer: Sean Mullan <mullan at openjdk.org>
Date:      2024-09-26 13:20:14 +0000
URL:       https://git.openjdk.org/leyden/commit/95d3e9d199600bac0284f9151b99aef152e027ac

8339560: Unaddressed comments during code review of JDK-8337664

Reviewed-by: mullan

- test/jdk/sun/security/ssl/X509TrustManagerImpl/Entrust/Distrust.java
- test/jdk/sun/security/ssl/X509TrustManagerImpl/Symantec/Distrust.java
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/Distrust.java
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/Entrust.java
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/Symantec.java
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/entrust/affirmtrustcommercialca-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/entrust/affirmtrustnetworkingca-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/entrust/affirmtrustpremiumca-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/entrust/affirmtrustpremiumeccca-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/entrust/entrust2048ca-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/entrust/entrustevca-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/entrust/entrustrootcaec1-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/entrust/entrustrootcag2-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/entrust/entrustrootcag4-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/symantec/appleistca8g1-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/symantec/geotrustprimarycag2-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/symantec/geotrustprimarycag3-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/symantec/geotrustuniversalca-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/symantec/thawteprimaryrootca-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/symantec/thawteprimaryrootcag2-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/symantec/thawteprimaryrootcag3-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/symantec/verisignclass3g3ca-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/symantec/verisignclass3g4ca-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/symantec/verisignclass3g5ca-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/symantec/verisignclass3g5ca-codesigning-chain.pem
= test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/symantec/verisignuniversalrootca-chain.pem

Changeset: e36ce5f0
Branch: hermetic-java-runtime
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2024-09-26 15:11:03 +0000
URL:       https://git.openjdk.org/leyden/commit/e36ce5f0341e8d0ec06cb12d0b2c0aa084401021

8336942: Improve test coverage for class loading elements with annotations of different retentions

Reviewed-by: vromero

! test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java

Changeset: 376056ca
Branch: hermetic-java-runtime
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-26 15:14:21 +0000
URL:       https://git.openjdk.org/leyden/commit/376056ca48fb5dbe3d57cea01a9fbf2ea4c35616

8336468: Reflection and MethodHandles should use more precise initializer checks

Reviewed-by: liach, coleenp

! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/methodHandles.cpp
! src/hotspot/share/runtime/reflection.cpp

Changeset: aeaa4f78
Branch: hermetic-java-runtime
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-09-26 15:20:51 +0000
URL:       https://git.openjdk.org/leyden/commit/aeaa4f78ebd634c2020d0f0dd100fcb55d5130af

8336895: BufferedReader doesn't read full \r\n line ending when it doesn't fit in buffer

Reviewed-by: jpai, alanb

! src/java.base/share/classes/java/io/BufferedInputStream.java
! src/java.base/share/classes/java/io/BufferedOutputStream.java
! src/java.base/share/classes/java/io/BufferedReader.java
! src/java.base/share/classes/java/io/BufferedWriter.java

Changeset: aceae76f
Branch: hermetic-java-runtime
Author:    Maxim Kartashev <mkartashev at openjdk.org>
Date:      2024-09-26 15:40:31 +0000
URL:       https://git.openjdk.org/leyden/commit/aceae76fb5853ab65851225aeb35a425af8f7af8

8339460: CDS error when module is located in a directory with space in the name

Reviewed-by: ccheung, iklam

! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/cds/classListWriter.cpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/classLoader.hpp
! src/hotspot/share/classfile/classLoaderExt.cpp
! test/hotspot/jtreg/TEST.groups
+ test/hotspot/jtreg/runtime/cds/appcds/complexURI/ComplexURITest.java
+ test/hotspot/jtreg/runtime/cds/appcds/complexURI/mypackage/Another.java
+ test/hotspot/jtreg/runtime/cds/appcds/complexURI/mypackage/Main.java

Changeset: 8225a5f5
Branch: hermetic-java-runtime
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-09-26 16:03:04 +0000
URL:       https://git.openjdk.org/leyden/commit/8225a5f58a62ddf4acbb879bfcb53cf7bfd8542f

8340981: Update citations to "Hacker's Delight"

Reviewed-by: bpb, iris, liach, jwaters

! src/java.base/share/classes/java/lang/Integer.java
! src/java.base/share/classes/java/lang/Long.java

Changeset: bb040ef4
Branch: hermetic-java-runtime
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-09-26 16:04:45 +0000
URL:       https://git.openjdk.org/leyden/commit/bb040ef4cc2b626f282cbf6af5b359d1c2505385

8340983: Use index and definition tags in Object and Double

Reviewed-by: bpb, liach

! src/java.base/share/classes/java/lang/Double.java
! src/java.base/share/classes/java/lang/Object.java

Changeset: a02d895f
Branch: hermetic-java-runtime
Author:    Ravi Gupta <rgupta at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-09-26 16:31:31 +0000
URL:       https://git.openjdk.org/leyden/commit/a02d895f7ad59fe33f8a761dbd7bceb0b8dfefc0

8333403: Write a test to check various components events are triggered properly

Reviewed-by: aivanov

+ test/jdk/java/awt/Component/ComponentEventTest.java

Changeset: 1447967f
Branch: hermetic-java-runtime
Author:    Fernando Guallini <fguallini at openjdk.org>
Committer: Rajan Halade <rhalade at openjdk.org>
Date:      2024-09-26 16:47:49 +0000
URL:       https://git.openjdk.org/leyden/commit/1447967f53fe27f67e4bb766464f941e39506d41

8339261: Logs truncated in test javax/net/ssl/DTLS/DTLSRehandshakeTest.java

Reviewed-by: rhalade, hchao

! test/jdk/javax/net/ssl/DTLS/TEST.properties

Changeset: 5d062e24
Branch: hermetic-java-runtime
Author:    Doug Simon <dnsimon at openjdk.org>
Date:      2024-09-26 19:36:26 +0000
URL:       https://git.openjdk.org/leyden/commit/5d062e248ec4be7b35f85c341e76aa6d8d6d8b2b

8340576: Some JVMCI flags are inconsistent

Reviewed-by: never

! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/share/compiler/oopMap.inline.hpp
! src/hotspot/share/jvmci/jvmci_globals.cpp
! src/hotspot/share/jvmci/jvmci_globals.hpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/escapeBarrier.hpp
! src/hotspot/share/runtime/sharedRuntime.cpp

Changeset: 2349bb7a
Branch: hermetic-java-runtime
Author:    Todd V. Jonker <jonker at amazon.com>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2024-09-26 21:38:08 +0000
URL:       https://git.openjdk.org/leyden/commit/2349bb7ace0c40c0f19dee81b4a86bed0e855043

8340974: Ambiguous name of jtreg property vm.libgraal.enabled

Reviewed-by: dnsimon, phh

! test/hotspot/jtreg/TEST.ROOT
! test/jtreg-ext/requires/VMProps.java
! test/lib/jdk/test/whitebox/code/Compiler.java

Changeset: e6373b52
Branch: hermetic-java-runtime
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-09-26 21:54:30 +0000
URL:       https://git.openjdk.org/leyden/commit/e6373b52380b35ed13b5ea308dfd5ade454f0e99

8340679: Misc tests fail assert(!set || SafepointSynchronize::is_at_safepoint()) failed: set once or at safepoint

Reviewed-by: matsaave, iklam

! src/hotspot/share/classfile/systemDictionary.cpp

Changeset: 1bc13a1c
Branch: hermetic-java-runtime
Author:    Florian Weimer <fweimer at openjdk.org>
Date:      2024-09-26 22:37:45 +0000
URL:       https://git.openjdk.org/leyden/commit/1bc13a1c10a580f84f1b7686c95344ec2633f611

8340552: Harden TzdbZoneRulesCompiler against missing zone names

Reviewed-by: andrew, jlu, naoto

! make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesCompiler.java

Changeset: 85dba479
Branch: hermetic-java-runtime
Author:    Hannes Walln?fer <hannesw at openjdk.org>
Date:      2024-09-27 06:34:02 +0000
URL:       https://git.openjdk.org/leyden/commit/85dba479256a59ea66997d5c408f290e6b5ad384

8325090: javadoc fails when -subpackages option is used with non-modular -source

Reviewed-by: liach, jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java
+ test/langtools/jdk/javadoc/tool/subpackageNoModules/SubpackageNoModules.java

Changeset: 2a2ecc99
Branch: hermetic-java-runtime
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-09-27 07:27:29 +0000
URL:       https://git.openjdk.org/leyden/commit/2a2ecc994e02049d6d84f083b8e92a51368577bf

8339475: Clean up return code handling for pthread calls in library coding

Reviewed-by: clanger, jwaters

! src/java.base/macosx/native/libjli/java_md_macosx.m
! src/java.base/unix/native/libjli/java_md_common.c
! src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m
! src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c

Changeset: 9003e2c5
Branch: hermetic-java-runtime
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2024-09-27 08:28:59 +0000
URL:       https://git.openjdk.org/leyden/commit/9003e2c519e63fa547e2f072e47f74057094efa2

8341027: Crash in java/runtime/Unsafe/InternalErrorTest when running with -XX:-UseCompressedClassPointers

Reviewed-by: aboldtch, coleenp

! test/hotspot/jtreg/runtime/Unsafe/InternalErrorTest.java

Changeset: 6587909c
Branch: hermetic-java-runtime
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-27 09:44:00 +0000
URL:       https://git.openjdk.org/leyden/commit/6587909c7db6482bda92d314096a2a1795900ffd

8341015: OopStorage location decoder crashes accessing non-initalized OopStorage

Reviewed-by: kbarrett, tschatzl

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

Changeset: 25e89291
Branch: hermetic-java-runtime
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-09-27 10:58:10 +0000
URL:       https://git.openjdk.org/leyden/commit/25e892911dabe32cc0d13b0d4322c5d89585b8f1

8340620: Fix -Wzero-as-null-pointer-constant warnings for CompressedOops

Reviewed-by: shade, stefank, mli, amitkumar

! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/s390/s390.ad
! src/hotspot/share/oops/compressedOops.cpp

Changeset: 12de4fbc
Branch: hermetic-java-runtime
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-09-27 15:02:01 +0000
URL:       https://git.openjdk.org/leyden/commit/12de4fbce7a314a1c5c84340526cd65b9a4a29d1

8340826: Should not send unload notification for scratch classes

Reviewed-by: sspitsyn, coleenp

! src/hotspot/share/code/dependencyContext.cpp
! src/hotspot/share/code/dependencyContext.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp
! src/hotspot/share/oops/instanceKlass.cpp

Changeset: 68c4f368
Branch: hermetic-java-runtime
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2024-09-27 16:21:05 +0000
URL:       https://git.openjdk.org/leyden/commit/68c4f36857a8ce62731cc73e251e969d48e526ef

8340024: In ClassReader, extract a constant for the superclass supertype_index

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java

Changeset: 5aae3d40
Branch: hermetic-java-runtime
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2024-09-27 16:26:30 +0000
URL:       https://git.openjdk.org/leyden/commit/5aae3d40856d92e1e0ff744cb1a0d3421c3dfd5b

8341096: ProblemList compiler/cha/TypeProfileFinalMethod.java in Xcomp mode

Reviewed-by: azvegint

! test/hotspot/jtreg/ProblemList-Xcomp.txt

Changeset: 824a297a
Branch: hermetic-java-runtime
Author:    Rajan Halade <rhalade at openjdk.org>
Date:      2024-09-27 16:57:02 +0000
URL:       https://git.openjdk.org/leyden/commit/824a297aae15ba16cf6d7aded4b95fc9d6bf55e5

8341057: Add 2 SSL.com TLS roots

Reviewed-by: mullan

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

Changeset: 65200a95
Branch: hermetic-java-runtime
Author:    Xiaolong Peng <xpeng at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-27 17:06:18 +0000
URL:       https://git.openjdk.org/leyden/commit/65200a9589e46956a2194b20c4c90d003351a539

8340490: Shenandoah: Optimize ShenandoahPacer

Reviewed-by: shade, kdnilsen

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

Changeset: f554c3ff
Branch: hermetic-java-runtime
Author:    Rajan Halade <rhalade at openjdk.org>
Date:      2024-09-27 17:16:13 +0000
URL:       https://git.openjdk.org/leyden/commit/f554c3ffce7599fdb535b03db4a6ea96870b3c2d

8341059: Change Entrust TLS distrust date to November 12, 2024

Reviewed-by: mullan

! src/java.base/share/classes/sun/security/validator/CADistrustPolicy.java
! src/java.base/share/classes/sun/security/validator/EntrustTLSPolicy.java
! src/java.base/share/conf/security/java.security
! test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/Entrust.java

Changeset: a7bfced6
Branch: hermetic-java-runtime
Author:    Yagmur Eren <yagmur.eren at oracle.com>
Committer: Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-09-27 17:36:48 +0000
URL:       https://git.openjdk.org/leyden/commit/a7bfced60540fe8d4fa7360bff512337ea47b890

8337679: Memset warning in src/hotspot/share/adlc/adlArena.cpp

Reviewed-by: stefank, thartmann, jwaters

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

Changeset: 082125d6
Branch: hermetic-java-runtime
Author:    Justin Lu <jlu at openjdk.org>
Date:      2024-09-27 18:26:08 +0000
URL:       https://git.openjdk.org/leyden/commit/082125d61e4b7e0fd53528c0271ca8be621f242b

8340404: CharsetProvider specification updates

Reviewed-by: alanb, naoto

! src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java
+ test/jdk/java/nio/charset/spi/CharsetProviderAsModuleTest.java
= test/jdk/java/nio/charset/spi/provider/module-info.java
+ test/jdk/java/nio/charset/spi/provider/spi/BazProvider.java

Changeset: ed140f5d
Branch: hermetic-java-runtime
Author:    Boris Ulasevich <bulasevich at openjdk.org>
Date:      2024-09-27 23:11:41 +0000
URL:       https://git.openjdk.org/leyden/commit/ed140f5d5e2dec1217e2efbee815d84306de0563

8341101: [ARM32] Error: ShouldNotReachHere() in TemplateInterpreterGenerator::generate_math_entry after 8338694

Reviewed-by: shade

! src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp

Changeset: 73ebb848
Branch: hermetic-java-runtime
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-09-27 23:34:04 +0000
URL:       https://git.openjdk.org/leyden/commit/73ebb848fdb66861e912ea747c039ddd1f7a5f48

8340721: Clarify special case handling of unboxedType and getWildcardType

Reviewed-by: prappo, mcimadamore

! src/java.compiler/share/classes/javax/lang/model/util/Types.java
+ test/langtools/tools/javac/processing/model/util/types/TestInvalidInputs.java

Changeset: af4e0555
Branch: hermetic-java-runtime
Author:    Jiangli Zhou <jianglizhou at google.com>
Date:      2024-09-27 17:43:43 +0000
URL:       https://git.openjdk.org/leyden/commit/af4e0555ca6ecb8c9ff9de16d847bb95cc3ab154

Merge branch 'master' into hermetic-java-runtime

Update src/java.base/share/classes/java/security/Security.java to handle hermetic modules image bundled java.security.

With https://github.com/openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab, it has a case supporting loading security property file specified by java.security.properties system property using URL. I think that can already take care the case for the extra security property built into the hermetic JAR/image. We don't need additional change for handling that.

! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/classfile/classLoader.cpp
! src/java.base/share/classes/java/security/Security.java
! src/java.base/share/native/libjli/java.c
! src/java.base/share/native/libjli/java.h
! src/java.base/unix/native/libjli/java_md.c
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/classfile/classLoader.cpp
! src/java.base/share/classes/java/security/Security.java
! src/java.base/share/native/libjli/java.c
! src/java.base/share/native/libjli/java.h
! src/java.base/unix/native/libjli/java_md.c


From adinn at openjdk.org  Mon Sep 30 09:55:52 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 30 Sep 2024 09:55:52 GMT
Subject: RFR: Load coops base shift from AOTRuntimeConstants in AOT code
 [v5]
In-Reply-To: <ew48NMQpOPxwoWEHMWb6UTASfO-fLKlBXF2VKO0HKJ0=.735016c4-3842-434e-bb1e-58555a250b3a@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
 <ew48NMQpOPxwoWEHMWb6UTASfO-fLKlBXF2VKO0HKJ0=.735016c4-3842-434e-bb1e-58555a250b3a@github.com>
Message-ID: <BlZJqKNYPLKvez1TWoACRlQCdDtwxuaeypXY_ZMUY7A=.e0123e44-9a59-45c6-9b0b-1bd0b8293757@github.com>

On Thu, 26 Sep 2024 10:52:02 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> This PR modifies AOT compiled method code to load compressed oops base and shift constants via the AOTRuntimeConstants area rather than encode them as immediates. It also unlatches the currently forced setting of UseCompatibleCompressedOops, allowing the heap to be allocated wherever it will fit.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the force to wrangle register sets

Closing but keeping it available in case we find later that a better COOPs model can help improve peak performance when AOT code is replaced.

-------------

PR Comment: https://git.openjdk.org/leyden/pull/20#issuecomment-2382658040

From adinn at openjdk.org  Mon Sep 30 09:55:52 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 30 Sep 2024 09:55:52 GMT
Subject: Withdrawn: Load coops base shift from AOTRuntimeConstants in AOT code
In-Reply-To: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
References: <7poSfTPPQUbIbWzqEy2hpoMXNbbnjSnD7oCmEOrLJao=.ab547c9a-a8b7-4faf-be9e-e36f28894f52@github.com>
Message-ID: <mBAf_ELlQICOYPl98mYh1R8fkFBAKdAOxOJu5MWNiwo=.47fee1d0-67ee-4eeb-858b-bda15fbac118@github.com>

On Wed, 11 Sep 2024 14:01:59 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> This PR modifies AOT compiled method code to load compressed oops base and shift constants via the AOTRuntimeConstants area rather than encode them as immediates. It also unlatches the currently forced setting of UseCompatibleCompressedOops, allowing the heap to be allocated wherever it will fit.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/leyden/pull/20

From duke at openjdk.org  Mon Sep 30 18:52:56 2024
From: duke at openjdk.org (duke)
Date: Mon, 30 Sep 2024 18:52:56 GMT
Subject: git: openjdk/leyden: hermetic-java-runtime: 19 new changesets
Message-ID: <88d1cd7d-c334-421c-b187-96c70bb921fb@openjdk.org>

Changeset: ade17ecb
Branch: hermetic-java-runtime
Author:    Phil Race <prr at openjdk.org>
Date:      2024-09-29 17:05:01 +0000
URL:       https://git.openjdk.org/leyden/commit/ade17ecb6cb5125d048401a878b557e5afefc08c

8340560: Open Source several AWT/2D font and rendering tests

Reviewed-by: kizune

+ test/jdk/sun/awt/font/CacheFlushTest.java
+ test/jdk/sun/awt/font/TestArabicHebrew.java
+ test/jdk/sun/awt/font/TestDevTransform.java
+ test/jdk/sun/awt/windows/TestPen.java

Changeset: dd569909
Branch: hermetic-java-runtime
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-30 02:43:32 +0000
URL:       https://git.openjdk.org/leyden/commit/dd56990962d58e4f482773f67bc43383d7748536

8340639: Open source few more AWT List tests

Reviewed-by: prr

+ test/jdk/java/awt/List/HorizScrollWorkTest.java
+ test/jdk/java/awt/List/HorizScrollbarEraseTest.java
+ test/jdk/java/awt/List/ScrollbarPresenceTest.java
+ test/jdk/java/awt/List/SetForegroundTest.java

Changeset: ae4d2f15
Branch: hermetic-java-runtime
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-09-30 02:43:49 +0000
URL:       https://git.openjdk.org/leyden/commit/ae4d2f15901bf02efceaac26ee4aa3ae666bf467

8340621: Open source several AWT List tests

Reviewed-by: prr

+ test/jdk/java/awt/List/DisabledListIsGreyTest.java
+ test/jdk/java/awt/List/ListFrameResizeTest.java
+ test/jdk/java/awt/List/MultiSelectionListCrashTest.java
+ test/jdk/java/awt/List/ScrollbarPositionTest.java
+ test/jdk/java/awt/List/SelectedItemVisibilityTest.java

Changeset: 6514aef8
Branch: hermetic-java-runtime
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2024-09-30 06:20:08 +0000
URL:       https://git.openjdk.org/leyden/commit/6514aef8403fa5fc09e5c064a783ff0f1fccd0cf

8340419: ZGC: Create an UseLargePages adaptation of TestAllocateHeapAt.java

Reviewed-by: stefank, sjohanss, jsikstro

+ test/hotspot/jtreg/gc/z/TestAllocateHeapAtWithHugeTLBFS.java

Changeset: 822a7738
Branch: hermetic-java-runtime
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Date:      2024-09-30 06:38:42 +0000
URL:       https://git.openjdk.org/leyden/commit/822a773873c42ea27a6be90da92b2b2c9fb8caee

8340605: Open source several AWT PopupMenu tests

Reviewed-by: tr

+ test/jdk/java/awt/PopupMenu/PeripheryOfScreen.java
+ test/jdk/java/awt/PopupMenu/PopupLeadingSeparatorTest.java
+ test/jdk/java/awt/PopupMenu/PopupMenuShowTest.java
+ test/jdk/java/awt/PopupMenu/PopupMenuWithMenuBar.java
+ test/jdk/java/awt/PopupMenu/PopupOnButton.java

Changeset: 988a531b
Branch: hermetic-java-runtime
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-09-30 07:02:55 +0000
URL:       https://git.openjdk.org/leyden/commit/988a531b097ccbd699d233059d73f41cae24dc5b

8340181: Shenandoah: Cleanup ShenandoahRuntime stubs

Reviewed-by: adinn, phh, wkemper

! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
! src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp
! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.hpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRuntime.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRuntime.hpp

Changeset: 52ba7282
Branch: hermetic-java-runtime
Author:    Sebastian L?vdahl <sebastian.lovdahl at hibox.tv>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2024-09-30 08:33:12 +0000
URL:       https://git.openjdk.org/leyden/commit/52ba72823be0c969ab873ead2863ec48f883210b

8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)

Co-authored-by: Larry Cable <larry.cable at oracle.com>
Reviewed-by: kevinw, sgehwolf

! src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
! test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java

Changeset: 475b8943
Branch: hermetic-java-runtime
Author:    Mikhail Ablakatov <164922675+mikabl-arm at users.noreply.github.com>
Date:      2024-09-30 09:02:59 +0000
URL:       https://git.openjdk.org/leyden/commit/475b8943c672349609a4839ce0a02ef995764698

8322770: Implement C2 VectorizedHashCode on AArch64

Reviewed-by: aph, adinn

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/assembler_aarch64.hpp
! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/stubRoutines_aarch64.cpp
! src/hotspot/cpu/aarch64/stubRoutines_aarch64.hpp
! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp
+ src/hotspot/share/utilities/intpow.hpp
! test/hotspot/gtest/aarch64/aarch64-asmtest.py
! test/hotspot/gtest/aarch64/asmtest.out.h

Changeset: 1cf26a51
Branch: hermetic-java-runtime
Author:    Oli Gillespie <ogillespie at openjdk.org>
Committer: Hamlin Li <mli at openjdk.org>
Date:      2024-09-30 10:53:20 +0000
URL:       https://git.openjdk.org/leyden/commit/1cf26a5179e619f17909426fdb26a3fb3b748483

8341013: Optimize x86/aarch64 MD5 intrinsics by reducing data dependency

Reviewed-by: mli, ascarpino

! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/x86/macroAssembler_x86_md5.cpp

Changeset: 58b6fc5b
Branch: hermetic-java-runtime
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2024-09-30 10:56:52 +0000
URL:       https://git.openjdk.org/leyden/commit/58b6fc5baa0931fa6f2aa37bf0bb125497cf6cc9

8341197: [BACKOUT] 8322770: Implement C2 VectorizedHashCode on AArch64

Reviewed-by: shade, jpai

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/assembler_aarch64.hpp
! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/stubRoutines_aarch64.cpp
! src/hotspot/cpu/aarch64/stubRoutines_aarch64.hpp
! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp
- src/hotspot/share/utilities/intpow.hpp
! test/hotspot/gtest/aarch64/aarch64-asmtest.py
! test/hotspot/gtest/aarch64/asmtest.out.h

Changeset: e19c7d80
Branch: hermetic-java-runtime
Author:    Jayathirth D V <jdv at openjdk.org>
Date:      2024-09-30 11:24:48 +0000
URL:       https://git.openjdk.org/leyden/commit/e19c7d80f722395583fbdb4cc10dc9051c8602f2

8340874: Open source some of the AWT Geometry/Button tests

Reviewed-by: prr

+ test/jdk/java/awt/Button/BadActionEventTest/BadActionEventTest.java
+ test/jdk/java/awt/geom/Arc2D/Arc2DHitTest.java
+ test/jdk/java/awt/geom/Arc2D/BoundsBug.java
+ test/jdk/java/awt/geom/Area/Translate.java

Changeset: 180affc5
Branch: hermetic-java-runtime
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
Date:      2024-09-30 12:28:35 +0000
URL:       https://git.openjdk.org/leyden/commit/180affc5718c9bf2f009d6a7aa129cc36335384a

8320318: ObjectMonitor Responsible thread

Reviewed-by: aboldtch, coleenp, pchilanomate, eosterlund

! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.cpp
! src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
! src/hotspot/share/opto/c2_CodeStubs.hpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/objectMonitor.cpp
! src/hotspot/share/runtime/objectMonitor.hpp
! src/hotspot/share/runtime/objectMonitor.inline.hpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! test/micro/org/openjdk/bench/vm/lang/LockUnlock.java

Changeset: cff420d8
Branch: hermetic-java-runtime
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Date:      2024-09-30 13:06:49 +0000
URL:       https://git.openjdk.org/leyden/commit/cff420d8d3cfbbb729ee47b00c8fe38e410eab1a

8339711: ZipFile.Source.initCEN needlessly reads END header

Reviewed-by: lancea, jpai, redestad

! src/java.base/share/classes/java/util/zip/ZipFile.java
! test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java
! test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java

Changeset: 860d49db
Branch: hermetic-java-runtime
Author:    Ramkumar Sunderbabu <rsunderbabu at openjdk.org>
Committer: Kim Barrett <kbarrett at openjdk.org>
Date:      2024-09-30 13:43:40 +0000
URL:       https://git.openjdk.org/leyden/commit/860d49db22cf352eaf1b3b20fff43d090f0eebc8

8211400: nsk.share.gc.Memory::getArrayLength returns wrong value

Reviewed-by: kbarrett, tschatzl

! test/hotspot/jtreg/vmTestbase/nsk/share/gc/Memory.java

Changeset: f1bf469b
Branch: hermetic-java-runtime
Author:    Shaojin Wen <swen at openjdk.org>
Date:      2024-09-30 14:12:01 +0000
URL:       https://git.openjdk.org/leyden/commit/f1bf469b4ee07b48b629a126111e307d3cab7fd7

8341199: Use ClassFile's new API loadConstant(int)

Reviewed-by: liach, redestad

! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/EventClassBuilder.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java

Changeset: 4168faf5
Branch: hermetic-java-runtime
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-09-30 16:10:02 +0000
URL:       https://git.openjdk.org/leyden/commit/4168faf54c0558a7cff4ef6ac643bbbfdea0cec3

8341100: Add index entries for terms used in java.lang.Class

Reviewed-by: liach

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

Changeset: 5586f83e
Branch: hermetic-java-runtime
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-09-30 16:13:35 +0000
URL:       https://git.openjdk.org/leyden/commit/5586f83e34c2fe0bdc48daef8c456678cea55af1

8341064: Define anchor point and index term for "wrapper classes"

Reviewed-by: prappo, liach

! src/java.base/share/classes/java/lang/Boolean.java
! src/java.base/share/classes/java/lang/Byte.java
! src/java.base/share/classes/java/lang/Character.java
! src/java.base/share/classes/java/lang/Double.java
! src/java.base/share/classes/java/lang/Float.java
! src/java.base/share/classes/java/lang/Integer.java
! src/java.base/share/classes/java/lang/Long.java
! src/java.base/share/classes/java/lang/Short.java
! src/java.base/share/classes/java/lang/package-info.java
! src/java.compiler/share/classes/javax/lang/model/util/Types.java

Changeset: a6b31886
Branch: hermetic-java-runtime
Author:    Smita Kamath <svkamath at openjdk.org>
Date:      2024-09-30 17:00:13 +0000
URL:       https://git.openjdk.org/leyden/commit/a6b318863fa2775b6381977875b4f466af47beb8

8337632: AES-GCM Algorithm optimization for x86_64

Reviewed-by: jbhateja, sviswanathan

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.hpp
! src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64_ghash.cpp
! src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
! test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench.java
! test/micro/org/openjdk/bench/javax/crypto/full/BenchBase.java

Changeset: 2995f4b8
Branch: hermetic-java-runtime
Author:    Jiangli Zhou <jianglizhou at google.com>
Date:      2024-09-30 11:41:20 +0000
URL:       https://git.openjdk.org/leyden/commit/2995f4b8c076702593019186f9f466899bbfdb15

Merge branch 'master' into hermetic-java-runtime