From duke at openjdk.org  Thu Jan  4 00:35:28 2024
From: duke at openjdk.org (duke)
Date: Thu, 4 Jan 2024 00:35:28 GMT
Subject: git: openjdk/leyden: premain: Validate preload code before publishing
Message-ID: <055554a7-0413-4072-97ea-5ff57ff6658d@openjdk.org>

Changeset: ffb0c323
Author:    Vladimir Kozlov <vladimir.kozlov at oracle.com>
Date:      2024-01-03 16:34:33 +0000
URL:       https://git.openjdk.org/leyden/commit/ffb0c32338f785d1485c310006924413b290c7b8

Validate preload code before publishing

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


From duke at openjdk.org  Fri Jan  5 14:49:52 2024
From: duke at openjdk.org (duke)
Date: Fri, 5 Jan 2024 14:49:52 GMT
Subject: git: openjdk/leyden: computed-constants: 123 new changesets
Message-ID: <bc514404-0dbe-406e-91a7-68e4315f04d8@openjdk.org>

Changeset: f1eb1252
Author:    Per Minborg <pminborg at gmail.com>
Date:      2024-01-02 13:30:00 +0000
URL:       https://git.openjdk.org/leyden/commit/f1eb125284517cca572e884471aabc683c4992aa

Start modeling a new API

+ src/java.base/share/classes/java/lang/ComputedConstant2.java
! src/java.base/share/classes/java/lang/Constant.java
+ test/jdk/java/lang/ComputedConstant/BasicComputedConstant2Test.java

Changeset: ce4b257f
Author:    Jorn Vernee <jvernee at openjdk.org>
Date:      2023-12-11 19:05:40 +0000
URL:       https://git.openjdk.org/leyden/commit/ce4b257fa539d35a7d14bba2d5d3342093d714e1

8320886: Unsafe_SetMemory0 is not guarded

Reviewed-by: dholmes, fparain

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/share/prims/unsafe.cpp
! test/hotspot/jtreg/runtime/Unsafe/InternalErrorTest.java

Changeset: 6359b4ec
Author:    Yuri Gaevsky <yuri.gaevsky at gmail.com>
Committer: Vladimir Kempik <vkempik at openjdk.org>
Date:      2023-12-12 06:35:09 +0000
URL:       https://git.openjdk.org/leyden/commit/6359b4ec2303e9cd81f3cbcfdf1c3e015278cb7b

8318217: RISC-V: C2 VectorizedHashCode

Reviewed-by: mli, fyang

! 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/vm_version_riscv.cpp

Changeset: 973bcdab
Author:    Guoxiong Li <gli at openjdk.org>
Date:      2023-12-12 07:19:50 +0000
URL:       https://git.openjdk.org/leyden/commit/973bcdab81f754671de4c55656b8fb921bba4f61

8321631: Fix comments in access.hpp

Reviewed-by: eosterlund, stefank

! src/hotspot/share/oops/access.hpp

Changeset: b8c0b2fd
Author:    Alan Bateman <alanb at openjdk.org>
Date:      2023-12-12 07:55:56 +0000
URL:       https://git.openjdk.org/leyden/commit/b8c0b2fd8c1331692f4ee397f1115ed48d8940d1

8321594: NativeThreadSet should use placeholder for virtual threads

Reviewed-by: bpb

! src/java.base/share/classes/sun/nio/ch/NativeThreadSet.java
! src/java.base/unix/classes/sun/nio/ch/NativeThread.java
! src/java.base/windows/classes/sun/nio/ch/NativeThread.java

Changeset: 2611a49e
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2023-12-12 08:36:55 +0000
URL:       https://git.openjdk.org/leyden/commit/2611a49ea13ee7a07f22692c3a4b32856ec5898f

8321287: Remove unused enum style in Prefetch

Reviewed-by: fparain, gziemski

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

Changeset: d5214a42
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2023-12-12 09:45:27 +0000
URL:       https://git.openjdk.org/leyden/commit/d5214a4288e77e66c83c03c8f6b7e8456c01ca81

8321814: G1: Remove unused G1RemSetScanState::_collection_set_iter_state

Reviewed-by: tschatzl

! src/hotspot/share/gc/g1/g1RemSet.cpp

Changeset: e1fd663f
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2023-12-12 09:58:41 +0000
URL:       https://git.openjdk.org/leyden/commit/e1fd663f224909c09f2f6fab7ad20f7b7864b62b

8311306: Test com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed: out of expected range

Reviewed-by: sspitsyn

! test/jdk/com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java

Changeset: 6f482406
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2023-12-12 10:02:01 +0000
URL:       https://git.openjdk.org/leyden/commit/6f4824068dbd0631ac73c79de479245e0c53ed81

8321729: Remove 'orb' field in RMIConnector

Reviewed-by: rriggs, dfuchs

! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java

Changeset: 7d903964
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2023-12-12 10:35:40 +0000
URL:       https://git.openjdk.org/leyden/commit/7d903964fb1b8840664d4f0f9a4fa1a53111a856

8321422: Test gc/g1/pinnedobjs/TestPinnedObjectTypes.java times out after completion

Reviewed-by: iwalulya, ayang

! test/hotspot/jtreg/gc/g1/pinnedobjs/TestPinnedObjectTypes.java

Changeset: c5168526
Author:    Hannes Walln?fer <hannesw at openjdk.org>
Date:      2023-12-12 11:27:31 +0000
URL:       https://git.openjdk.org/leyden/commit/c51685267c7bd5a7cee27ebc2bf0d9899cda9d4c

8321889: JavaDoc method references with wrong (nested) type

Reviewed-by: alanb

! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.compiler/share/classes/javax/lang/model/element/package-info.java
! src/java.smartcardio/share/classes/javax/smartcardio/CardTerminals.java

Changeset: 5718039a
Author:    Jamil Nimeh <jnimeh at openjdk.org>
Date:      2023-12-12 14:36:58 +0000
URL:       https://git.openjdk.org/leyden/commit/5718039a46ae51fa9b7042fe7163e3637e981b05

8321542: C2: Missing ChaCha20 stub for x86_32 leads to crashes

Reviewed-by: chagedorn, shade

! src/hotspot/cpu/x86/vm_version_x86.cpp

Changeset: df4ed7ef
Author:    Christian Stein <cstein at openjdk.org>
Date:      2023-12-12 15:26:21 +0000
URL:       https://git.openjdk.org/leyden/commit/df4ed7eff7cc4afb2f0bcfdbb2489715ab209737

8321739: Source launcher fails with "Not a directory" error

Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java
! test/langtools/tools/javac/launcher/GetResourceTest.java
+ test/langtools/tools/javac/launcher/src/java

Changeset: b25ed57b
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2023-12-12 18:30:41 +0000
URL:       https://git.openjdk.org/leyden/commit/b25ed57b764fc485e4e8ca4118ffb1cc70fdfe7f

8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED

Reviewed-by: aivanov

! src/java.desktop/windows/classes/sun/awt/windows/WDesktopPeer.java
! src/java.desktop/windows/native/libawt/windows/awt_Desktop.cpp

Changeset: a3447ec6
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2023-12-12 18:44:43 +0000
URL:       https://git.openjdk.org/leyden/commit/a3447ec6562c5b4570da964d08ce8ae4c157c961

8321827: Remove unnecessary suppress warnings annotations from the printing processor

Reviewed-by: jlaskey

! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java

Changeset: aadf3680
Author:    Justin Lu <jlu at openjdk.org>
Date:      2023-12-12 19:25:20 +0000
URL:       https://git.openjdk.org/leyden/commit/aadf36809c5daee8897601d33d8e6d6cedb57b9b

6230751: [Fmt-Ch] Recursive MessageFormats in ChoiceFormats ignore indicated subformats

Reviewed-by: naoto

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

Changeset: d5a96e3f
Author:    Alexandre Iline <shurailine at openjdk.org>
Date:      2023-12-12 20:41:18 +0000
URL:       https://git.openjdk.org/leyden/commit/d5a96e3f490ba9591f61b23dc2b06e65b0098140

8321621: Update JCov version to 3.0.16

Reviewed-by: erikj, alanb, ihse

! make/conf/jib-profiles.js

Changeset: 4fb5c128
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2023-12-12 20:55:17 +0000
URL:       https://git.openjdk.org/leyden/commit/4fb5c12813c6d447709d3fef690387ddab0e8dae

8321180: Condition for non-latin1 string size too large exception is off by one

Reviewed-by: rgiulietti

! src/java.base/share/classes/java/lang/StringUTF16.java
+ test/jdk/java/lang/String/CompactString/MaxSizeUTF16String.java

Changeset: ac07355f
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2023-12-12 21:00:50 +0000
URL:       https://git.openjdk.org/leyden/commit/ac07355f5507cdb3a741ec1122e5e9983eac3936

8320200: Use Elements predicates for record constructors to improve print output

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java

Changeset: 5463c9cd
Author:    Erik Joelsson <erikj at openjdk.org>
Date:      2023-12-12 21:31:41 +0000
URL:       https://git.openjdk.org/leyden/commit/5463c9cd9a0a6f95f90787c330679b2ea78690c6

8321557: Move SOURCE line verification for OracleJDK out of OpenJDK

Reviewed-by: ihse

! test/jdk/build/releaseFile/CheckReleaseFile.java

Changeset: 1b621f55
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2023-12-12 22:49:41 +0000
URL:       https://git.openjdk.org/leyden/commit/1b621f5527a0d7ae345d79f293357446ab7876d9

8321474: TestAutoCreateSharedArchiveUpgrade.java should be updated with JDK 21

Reviewed-by: dholmes, iklam

! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestAutoCreateSharedArchiveUpgrade.java

Changeset: 3d9d353e
Author:    David Holmes <dholmes at openjdk.org>
Date:      2023-12-12 23:00:48 +0000
URL:       https://git.openjdk.org/leyden/commit/3d9d353edb64dd364925481d7b7c8822beeaa117

8321825: Remove runtime/CompressedOops/CompressedClassPointers.java from the ProblemList

Reviewed-by: ccheung

! test/hotspot/jtreg/ProblemList.txt

Changeset: 8a0a6f8c
Author:    Sergey Tsypanov <stsypanov at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
Date:      2023-12-13 09:10:11 +0000
URL:       https://git.openjdk.org/leyden/commit/8a0a6f8c252082050c3714d9c14ad2972ac97ecf

8321279: Implement hashCode() in Heap-X-Buffer.java.template

Reviewed-by: alanb, bpb

! src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template
! test/micro/org/openjdk/bench/java/nio/ByteBuffers.java

Changeset: f573f6d2
Author:    Aleksei Voitylov <avoitylov at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2023-12-13 11:04:11 +0000
URL:       https://git.openjdk.org/leyden/commit/f573f6d233d5ea1657018c3c806fee0fac382ac3

8321515: ARM32: Move method resolution information out of the cpCache properly

Reviewed-by: shade

! src/hotspot/cpu/arm/interp_masm_arm.cpp
! src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp
! src/hotspot/cpu/arm/templateTable_arm.cpp

Changeset: 493b5bd2
Author:    Lei Zaakjyu <lizbing07734 at icloud.com>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
Date:      2023-12-13 11:18:38 +0000
URL:       https://git.openjdk.org/leyden/commit/493b5bd2fd5d4c2529e12a401f76178c1f4161fd

8293622: Cleanup use of G1ConcRefinementThreads

Reviewed-by: ayang, iwalulya

! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp
! src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp
! src/hotspot/share/gc/g1/g1FromCardCache.cpp
! src/hotspot/share/gc/g1/g1RemSetSummary.cpp

Changeset: 2a565ff3
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2023-12-13 11:18:51 +0000
URL:       https://git.openjdk.org/leyden/commit/2a565ff36809599117e4b38e18f15d1f29cd8fc0

8321808: G1: Use unsigned type for non-negative G1 flags

Reviewed-by: tschatzl, iwalulya

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

Changeset: 9320ef9b
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2023-12-13 12:43:41 +0000
URL:       https://git.openjdk.org/leyden/commit/9320ef9b29927b8fff52055d7a7a89db9b15b95b

8321973: Parallel: Remove unused methods in AdaptiveSizePolicy

Reviewed-by: tschatzl

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

Changeset: 7ece9e90
Author:    Jorn Vernee <jvernee at openjdk.org>
Date:      2023-12-13 17:34:37 +0000
URL:       https://git.openjdk.org/leyden/commit/7ece9e90c0198f92cdf8d620e346c4a9832724cd

8321400: java/foreign/TestStubAllocFailure.java fails with code cache exhaustion

Reviewed-by: mcimadamore

! test/jdk/java/foreign/TestAddressDereference.java
! test/jdk/java/foreign/TestStubAllocFailure.java
! test/jdk/java/foreign/TestUpcallException.java
! test/jdk/java/foreign/UpcallTestHelper.java
! test/jdk/java/foreign/critical/TestCriticalUpcall.java
! test/jdk/java/foreign/passheapsegment/TestPassHeapSegment.java
! test/lib/jdk/test/lib/process/OutputAnalyzer.java

Changeset: cf948548
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2023-12-13 18:47:04 +0000
URL:       https://git.openjdk.org/leyden/commit/cf948548c390c42ca63525d41a9d63ff31349c3a

8321565: [REDO] Heap dump does not contain virtual Thread stack references

Reviewed-by: sspitsyn, yyang, dholmes

! src/hotspot/share/services/heapDumper.cpp
! test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpParallelTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/HeapDump/VThreadInHeapDump.java

Changeset: c8ad7b7f
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2023-12-14 07:23:21 +0000
URL:       https://git.openjdk.org/leyden/commit/c8ad7b7f84ead3f850f034e1db6335bbbac41589

8321974: Crash in ciKlass::is_subtype_of because TypeAryPtr::_klass is not initialized

Reviewed-by: roland, kvn

! src/hotspot/share/opto/type.cpp
! src/hotspot/share/opto/type.hpp
+ test/hotspot/jtreg/compiler/c2/TestUninitializedKlassField.java

Changeset: ddbbd36e
Author:    Joe Wang <joehw at openjdk.org>
Date:      2023-12-14 07:45:02 +0000
URL:       https://git.openjdk.org/leyden/commit/ddbbd36e4b064b9e7433f0a55973d72cd6dbc0d3

8320279: Link issues in java.xml module-info.java

Reviewed-by: iris, lancea, naoto

! src/java.xml/share/classes/javax/xml/XMLConstants.java
! src/java.xml/share/classes/javax/xml/stream/XMLEventFactory.java
! src/java.xml/share/classes/javax/xml/stream/XMLInputFactory.java
! src/java.xml/share/classes/javax/xml/stream/XMLOutputFactory.java
! src/java.xml/share/classes/module-info.java

Changeset: d632d743
Author:    Daniel Lund?n <daniel.lunden at oracle.com>
Committer: Christian Hagedorn <chagedorn at openjdk.org>
Date:      2023-12-14 09:29:34 +0000
URL:       https://git.openjdk.org/leyden/commit/d632d743e018c69ecf423af75b65354e8ffaefc8

8321820: TestLoadNIdeal fails on 32-bit because -XX:+UseCompressedOops is not recognized

Reviewed-by: rcastanedalo, chagedorn, shade

! test/hotspot/jtreg/compiler/c2/irTests/igvn/TestLoadNIdeal.java

Changeset: d2ba3b1e
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2023-12-14 10:36:23 +0000
URL:       https://git.openjdk.org/leyden/commit/d2ba3b1ef733cb8435188993791f2af7f1d4f0eb

8312150: Remove -Xnoagent option

Reviewed-by: dholmes, alanb

! src/hotspot/share/runtime/arguments.cpp
! test/hotspot/jtreg/runtime/CommandLine/TestNullTerminatedFlags.java

Changeset: 2838a916
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2023-12-14 11:36:57 +0000
URL:       https://git.openjdk.org/leyden/commit/2838a916ab98cb0152f8b1e3f96eccca198af5e9

8288989: Make tests not depend on the source code

Reviewed-by: mcimadamore

! test/langtools/jdk/javadoc/doclet/testDocletExample/TestDocletExample.java
! test/langtools/tools/javac/api/snippets/TestJavaxToolsSnippets.java

Changeset: 5a97dbf6
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2023-12-14 12:30:47 +0000
URL:       https://git.openjdk.org/leyden/commit/5a97dbf60686d5d52027f4be80ccc00b7a78504d

8322034: Parallel: Remove unused methods in PSAdaptiveSizePolicy

Reviewed-by: kbarrett

! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.hpp

Changeset: 69014cd5
Author:    Daniel Lund?n <daniel.lunden at oracle.com>
Committer: Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
Date:      2023-12-14 13:09:39 +0000
URL:       https://git.openjdk.org/leyden/commit/69014cd55b59a0a63f4918fad575a6887640573e

8320682: [AArch64] C1 compilation fails with "Field too big for insn"

Reviewed-by: thartmann, aph, dlong

! src/hotspot/share/c1/c1_globals.hpp
! test/hotspot/jtreg/compiler/arguments/TestC1Globals.java

Changeset: 62b7c5ea
Author:    Darragh Clarke <dclarke at openjdk.org>
Date:      2023-12-14 13:24:19 +0000
URL:       https://git.openjdk.org/leyden/commit/62b7c5eaed1e6ffd6f2c8371eb4cf01dd9d53a06

8319647: Few java/lang/System/LoggerFinder/modules tests ignore vm flags

Reviewed-by: lmesnik

! test/jdk/java/lang/System/LoggerFinder/modules/JDKLoggerForImageTest.java
! test/jdk/java/lang/System/LoggerFinder/modules/JDKLoggerForJDKTest.java
! test/jdk/java/lang/System/LoggerFinder/modules/LoggerInImageTest.java
! test/jdk/java/lang/System/LoggerFinder/modules/NamedLoggerForImageTest.java
! test/jdk/java/lang/System/LoggerFinder/modules/NamedLoggerForJDKTest.java
! test/jdk/java/lang/System/LoggerFinder/modules/UnnamedLoggerForImageTest.java
! test/jdk/java/lang/System/LoggerFinder/modules/UnnamedLoggerForJDKTest.java

Changeset: 45a9ade3
Author:    Weijun Wang <weijun at openjdk.org>
Date:      2023-12-14 14:37:15 +0000
URL:       https://git.openjdk.org/leyden/commit/45a9ade3374e38205cdf3fd24282246830789d26

8202598: keytool -certreq output contains inconsistent line separators

Reviewed-by: hchao, mullan

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

Changeset: fde5b168
Author:    Aleksei Voitylov <avoitylov at openjdk.org>
Committer: Roger Riggs <rriggs at openjdk.org>
Date:      2023-12-14 14:39:04 +0000
URL:       https://git.openjdk.org/leyden/commit/fde5b16817c3263236993f2e8c2d2469610d99bd

8321514: UTF16 string gets constructed incorrectly from codepoints if CompactStrings is not enabled

Co-authored-by: Roger Riggs <rriggs at openjdk.org>
Reviewed-by: rriggs

! src/java.base/share/classes/java/lang/StringUTF16.java
! test/jdk/java/lang/String/Chars.java

Changeset: c328f958
Author:    Ben Perez <ben.perez at oracle.com>
Committer: Sean Mullan <mullan at openjdk.org>
Date:      2023-12-14 17:57:36 +0000
URL:       https://git.openjdk.org/leyden/commit/c328f9589ddc3a981a2c63801bd991f8e593e69f

8296787: Unify debug printing format of X.509 cert serial numbers

Reviewed-by: mullan, coffeys

! src/java.base/share/classes/java/security/cert/X509CertSelector.java
! src/java.base/share/classes/sun/security/jca/JCAUtil.java
! src/java.base/share/classes/sun/security/pkcs/SignerInfo.java
! src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java
! src/java.base/share/classes/sun/security/provider/certpath/Builder.java
! src/java.base/share/classes/sun/security/provider/certpath/CertId.java
! src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java
! src/java.base/share/classes/sun/security/provider/certpath/ForwardBuilder.java
! src/java.base/share/classes/sun/security/provider/certpath/OCSPResponse.java
! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java
! src/java.base/share/classes/sun/security/provider/certpath/Vertex.java
! src/java.base/share/classes/sun/security/ssl/SSLLogger.java
! src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java
! src/java.base/share/classes/sun/security/util/Debug.java
! src/java.base/share/classes/sun/security/x509/SerialNumber.java
! test/jdk/java/security/cert/X509CertSelectorTest.java
! test/lib/jdk/test/lib/security/TestCertificate.java
! test/lib/jdk/test/lib/security/TestTLSHandshake.java

Changeset: 8b24851b
Author:    Justin Lu <jlu at openjdk.org>
Date:      2023-12-14 21:16:19 +0000
URL:       https://git.openjdk.org/leyden/commit/8b24851b9d3619c41c7a6cdb9193ed26a9b732dc

8321480: ISO 4217 Amendment 176 Update

Reviewed-by: naoto

! make/jdk/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java
! src/java.base/share/classes/sun/util/resources/CurrencyNames.properties
! src/java.base/share/data/currency/CurrencyData.properties
! test/jdk/java/util/Currency/ValidateISO4217.java
! test/jdk/java/util/Currency/tablea1.txt

Changeset: d02bc873
Author:    David Holmes <dholmes at openjdk.org>
Date:      2023-12-14 21:24:17 +0000
URL:       https://git.openjdk.org/leyden/commit/d02bc873f806c90754da10c8a052e32836e895fd

8309981: Remove expired flags in JDK 23

Reviewed-by: alanb, kvn

! src/hotspot/share/runtime/arguments.cpp
! src/java.base/share/man/java.1

Changeset: 692be577
Author:    David Holmes <dholmes at openjdk.org>
Date:      2023-12-14 21:26:10 +0000
URL:       https://git.openjdk.org/leyden/commit/692be577385844bf00a01ff10e390e014191569f

8322065: Initial nroff manpage generation for JDK 23

Reviewed-by: alanb

! src/java.base/share/man/keytool.1
! src/java.rmi/share/man/rmiregistry.1
! src/java.scripting/share/man/jrunscript.1
! src/jdk.compiler/share/man/javac.1
! src/jdk.compiler/share/man/serialver.1
! src/jdk.hotspot.agent/share/man/jhsdb.1
! src/jdk.httpserver/share/man/jwebserver.1
! src/jdk.jartool/share/man/jar.1
! src/jdk.jartool/share/man/jarsigner.1
! src/jdk.javadoc/share/man/javadoc.1
! src/jdk.jcmd/share/man/jcmd.1
! src/jdk.jcmd/share/man/jinfo.1
! src/jdk.jcmd/share/man/jmap.1
! src/jdk.jcmd/share/man/jps.1
! src/jdk.jcmd/share/man/jstack.1
! src/jdk.jcmd/share/man/jstat.1
! src/jdk.jconsole/share/man/jconsole.1
! src/jdk.jdeps/share/man/javap.1
! src/jdk.jdeps/share/man/jdeprscan.1
! src/jdk.jdeps/share/man/jdeps.1
! src/jdk.jdi/share/man/jdb.1
! src/jdk.jfr/share/man/jfr.1
! src/jdk.jlink/share/man/jlink.1
! src/jdk.jlink/share/man/jmod.1
! src/jdk.jpackage/share/man/jpackage.1
! src/jdk.jshell/share/man/jshell.1
! src/jdk.jstatd/share/man/jstatd.1

Changeset: a7dde578
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2023-12-14 22:33:34 +0000
URL:       https://git.openjdk.org/leyden/commit/a7dde578a8c18ae7f38fe2061773eba6f8086aa4

8322057: Memory leaks in creating jfr symbol array

Reviewed-by: mgronlun

! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp
! src/hotspot/share/jfr/jni/jfrJavaSupport.hpp

Changeset: 6dfb8120
Author:    Joshua Cao <joshcao at amazon.com>
Committer: Y. Srinivas Ramakrishna <ysr at openjdk.org>
Date:      2023-12-15 00:35:37 +0000
URL:       https://git.openjdk.org/leyden/commit/6dfb8120c270a76fcba5a5c3c9ad91da3282d5fa

8321823: Remove redundant PhaseGVN transform_no_reclaim

Reviewed-by: chagedorn, phh

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

Changeset: 0be0775a
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2023-12-15 07:23:50 +0000
URL:       https://git.openjdk.org/leyden/commit/0be0775a762edbefacf4188b4787b039153fe670

8320397: RISC-V: Avoid passing t0 as temp register to MacroAssembler:: cmpxchg_obj_header/cmpxchgptr

Reviewed-by: rehn, fyang

! src/hotspot/cpu/riscv/gc/x/x_riscv.ad
! src/hotspot/cpu/riscv/gc/z/z_riscv.ad
! src/hotspot/cpu/riscv/interp_masm_riscv.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp

Changeset: b31454e3
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2023-12-15 07:42:39 +0000
URL:       https://git.openjdk.org/leyden/commit/b31454e36234091c3827c3b4d07f62345cb0cee4

8322098: os::Linux::print_system_memory_info enhance the THP output with /sys/kernel/mm/transparent_hugepage/hpage_pmd_size

Reviewed-by: mdoerr, lucy

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

Changeset: 20de541b
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2023-12-15 10:16:35 +0000
URL:       https://git.openjdk.org/leyden/commit/20de541b1304b4dc3a385f8a78f1215da237e4aa

8322040: Missing array bounds check in ClassReader.parameter

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
+ test/langtools/tools/javac/classreader/BadMethodParameter.java

Changeset: bdebf198
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2023-12-15 12:18:01 +0000
URL:       https://git.openjdk.org/leyden/commit/bdebf198bb0f4c3347ae9539d02ce0476e1176ce

8322175: test/langtools/tools/javac/classreader/BadMethodParameter.java doesn't compile

Reviewed-by: jlahoda

! test/langtools/tools/javac/classreader/BadMethodParameter.java

Changeset: 6311dabe
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2023-12-15 16:13:36 +0000
URL:       https://git.openjdk.org/leyden/commit/6311dabe68762749e4317cfa5e13005318bdceac

8322018: Test java/lang/String/CompactString/MaxSizeUTF16String.java fails with -Xcomp

Reviewed-by: jpai

! test/jdk/java/lang/String/CompactString/MaxSizeUTF16String.java

Changeset: 05f7f0ad
Author:    Tom Rodriguez <never at openjdk.org>
Date:      2023-12-15 17:25:24 +0000
URL:       https://git.openjdk.org/leyden/commit/05f7f0ade2c6c8ef57e884048cf159c46fa27b36

8321288: [JVMCI] HotSpotJVMCIRuntime doesn't clean up WeakReferences in resolvedJavaTypes

Reviewed-by: dnsimon, kvn

! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java

Changeset: 87ef7332
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2023-12-15 17:33:50 +0000
URL:       https://git.openjdk.org/leyden/commit/87ef73329f66e898d85eecea94a4104a13b3a2db

8321958: @param/@return descriptions of ZoneRules#isDaylightSavings() are incorrect

Reviewed-by: jlu, joehw, jpai

! src/java.base/share/classes/java/time/zone/ZoneRules.java

Changeset: dcdcd48d
Author:    Calvin Cheung <ccheung at openjdk.org>
Date:      2023-12-15 19:04:42 +0000
URL:       https://git.openjdk.org/leyden/commit/dcdcd48d8fbf076e12841e557ebbe70228c8a92b

8321479: java -D-D crashes

Reviewed-by: dholmes, iklam

! src/hotspot/share/runtime/arguments.cpp
+ test/hotspot/jtreg/runtime/CommandLine/UnrecognizedProperty.java

Changeset: b061b667
Author:    Alisen Chung <achung at openjdk.org>
Date:      2023-12-16 01:03:09 +0000
URL:       https://git.openjdk.org/leyden/commit/b061b6678fde891974d5b58cec963b3481099a8d

8322041: JDK 22 RDP1 L10n resource files update

Reviewed-by: almatvee, cstein, asemenyuk, joehw, jjg

! src/java.base/share/classes/sun/launcher/resources/launcher_de.properties
! src/java.base/share/classes/sun/launcher/resources/launcher_ja.properties
! src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_ja.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_zh_CN.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_de.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_zh_CN.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_de.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_ja.properties
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_zh_CN.properties
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_ja.properties
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_zh_CN.properties
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_ja.properties
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_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: 34351b7a
Author:    Steven Schlansker <stevenschlansker at gmail.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
Date:      2023-12-16 01:40:19 +0000
URL:       https://git.openjdk.org/leyden/commit/34351b7a7950a3b563748f40f2619374f62f9b16

8321892: Typo in log message logged by src/hotspot/share/nmt/virtualMemoryTracker.cpp

Reviewed-by: dholmes, azafari

! src/hotspot/share/nmt/virtualMemoryTracker.cpp

Changeset: f5538195
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2023-12-18 08:44:43 +0000
URL:       https://git.openjdk.org/leyden/commit/f55381950266088cc0284754b16663675867ac87

8317007: Add bulk removal of dead nmethods during class unloading

Reviewed-by: ayang, iwalulya

! src/hotspot/share/code/codeBlob.cpp
! src/hotspot/share/code/codeBlob.hpp
! src/hotspot/share/code/compiledMethod.hpp
! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/code/nmethod.hpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/gc/g1/g1CodeRootSet.cpp
! src/hotspot/share/gc/g1/g1CodeRootSet.hpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/heapRegionRemSet.cpp
! src/hotspot/share/gc/g1/heapRegionRemSet.hpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/serial/genMarkSweep.cpp
! src/hotspot/share/gc/serial/serialHeap.cpp
! src/hotspot/share/gc/shared/classUnloadingContext.cpp
! src/hotspot/share/gc/shared/classUnloadingContext.hpp
! src/hotspot/share/gc/shared/genCollectedHeap.cpp
! src/hotspot/share/gc/shared/genCollectedHeap.hpp
! src/hotspot/share/gc/shared/scavengableNMethods.cpp
! src/hotspot/share/gc/shared/scavengableNMethods.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp
! src/hotspot/share/gc/x/xHeap.cpp
! src/hotspot/share/gc/z/zGeneration.cpp

Changeset: 413dbf87
Author:    Lei Zaakjyu <lizbing07734 at icloud.com>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
Date:      2023-12-18 09:31:13 +0000
URL:       https://git.openjdk.org/leyden/commit/413dbf8757d20aa05407373b82957fbd3468f3ae

8322205: Parallel: Remove unused arg in PSCardTable::pre_scavenge

Reviewed-by: ayang, tschatzl

! src/hotspot/share/gc/parallel/psCardTable.cpp
! src/hotspot/share/gc/parallel/psCardTable.hpp
! src/hotspot/share/gc/parallel/psScavenge.cpp

Changeset: f696796e
Author:    Ivan Walulya <iwalulya at openjdk.org>
Date:      2023-12-18 09:43:53 +0000
URL:       https://git.openjdk.org/leyden/commit/f696796e888d62535e6c864ce6fdf912eef0c3ed

8280087: G1: Handle out-of-mark stack situations during reference processing more gracefully

Reviewed-by: tschatzl, ayang

! src/hotspot/share/gc/g1/g1Arguments.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp
+ test/hotspot/jtreg/gc/g1/TestMarkStackOverflow.java
! test/langtools/ProblemList.txt

Changeset: 341b4e09
Author:    Johan Sj?len <jsjolen at openjdk.org>
Date:      2023-12-18 09:45:26 +0000
URL:       https://git.openjdk.org/leyden/commit/341b4e09b73e5522f308b05c5a4ed9e161b14022

8321975: Print when add_reserved_region fails even in product mode

Reviewed-by: dholmes, stuefe

! src/hotspot/share/nmt/virtualMemoryTracker.cpp

Changeset: a247d0c7
Author:    Hamlin Li <mli at openjdk.org>
Date:      2023-12-18 10:31:29 +0000
URL:       https://git.openjdk.org/leyden/commit/a247d0c74bea50f11d24fb5f3576947c6901e567

8322209: RISC-V: Enable some tests related to MD5 instrinsic

Reviewed-by: luhenry, fyang

! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseMD5IntrinsicsOptionOnUnsupportedCPU.java
! test/hotspot/jtreg/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java

Changeset: ecff9c1e
Author:    Lei Zaakjyu <lizbing07734 at icloud.com>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
Date:      2023-12-18 11:05:48 +0000
URL:       https://git.openjdk.org/leyden/commit/ecff9c1ef7110ce80e5ba3e13af31e2c704eb3b0

8315040: Remove redundant check in WorkerPolicy::parallel_worker_threads

Reviewed-by: ayang, tschatzl

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

Changeset: 10335f60
Author:    Alexander Scherbatiy <alexsch at openjdk.org>
Date:      2023-12-18 12:11:41 +0000
URL:       https://git.openjdk.org/leyden/commit/10335f60f923aa4f315e64acb2bfd7bb06d47a1b

7001133: OutOfMemoryError by CustomMediaSizeName implementation

Reviewed-by: psadhukhan

! src/java.desktop/share/classes/sun/print/CustomMediaSizeName.java
! src/java.desktop/share/classes/sun/print/CustomMediaTray.java
! src/java.desktop/unix/classes/sun/print/CUPSPrinter.java
! src/java.desktop/unix/classes/sun/print/IPPPrintService.java
+ test/jdk/javax/print/CustomMediaSizeNameOOMETest.java

Changeset: febf8af4
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2023-12-18 12:57:01 +0000
URL:       https://git.openjdk.org/leyden/commit/febf8af4b5a220ba1a3336d31c701b0c1e4ba3ee

8322089: Parallel: Remove PSAdaptiveSizePolicy::set_survivor_size

Reviewed-by: tschatzl

! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.hpp

Changeset: 75d382d3
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2023-12-18 12:57:12 +0000
URL:       https://git.openjdk.org/leyden/commit/75d382d3db25e1d3592de3d8bf50d6ee85343e47

8322204: Parallel: Remove unused _collection_cost_margin_fraction

Reviewed-by: tschatzl

! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp
! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.hpp

Changeset: 5584ba36
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2023-12-18 13:30:34 +0000
URL:       https://git.openjdk.org/leyden/commit/5584ba36c6216f4d441d254e3135f7da20370475

8322097: Serial: Refactor CardTableRS::find_first_clean_card

Reviewed-by: tschatzl, iwalulya

! src/hotspot/share/gc/serial/cardTableRS.cpp
! src/hotspot/share/gc/shared/cardTable.hpp

Changeset: 7e1d26dd
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2023-12-18 14:29:00 +0000
URL:       https://git.openjdk.org/leyden/commit/7e1d26dd5cf665fb5cf64b8a0c3e6ff4f8d77360

8322287: Parallel: Remove unused arg in adjust_eden_for_pause_time and adjust_eden_for_minor_pause_time

Reviewed-by: tschatzl

! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp
! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.hpp

Changeset: c0a3b769
Author:    Yi-Fan Tsai <yftsai at amazon.com>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2023-12-18 15:19:16 +0000
URL:       https://git.openjdk.org/leyden/commit/c0a3b76958bd6766b18cab31b461c1b0ac2c65cd

8316197: Make tracing of inline cache available in unified logging

Reviewed-by: kvn, dholmes

! src/hotspot/cpu/aarch64/compiledIC_aarch64.cpp
! src/hotspot/cpu/arm/compiledIC_arm.cpp
! src/hotspot/cpu/ppc/compiledIC_ppc.cpp
! src/hotspot/cpu/riscv/compiledIC_riscv.cpp
! src/hotspot/cpu/s390/compiledIC_s390.cpp
! src/hotspot/cpu/x86/compiledIC_x86.cpp
! src/hotspot/share/code/compiledIC.cpp
! src/hotspot/share/logging/logTag.hpp
! src/hotspot/share/runtime/globals.hpp
! test/hotspot/jtreg/compiler/arguments/TestTraceICs.java

Changeset: a5122d7f
Author:    Yi-Fan Tsai <yftsai at amazon.com>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2023-12-18 15:20:59 +0000
URL:       https://git.openjdk.org/leyden/commit/a5122d7f6c36a4c98ea4bea7a7c8081e2a4dadca

8314029: Add file name parameter to Compiler.perfmap

Reviewed-by: cjplummer, eastigeevich

! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/codeCache.hpp
! src/hotspot/share/services/diagnosticCommand.cpp
! src/hotspot/share/services/diagnosticCommand.hpp
! src/jdk.jcmd/share/man/jcmd.1
! test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java

Changeset: 66aeb894
Author:    Afshin Zafari <azafari at openjdk.org>
Date:      2023-12-18 16:52:36 +0000
URL:       https://git.openjdk.org/leyden/commit/66aeb89469c20f1f1840773e59d3b45393418344

8315462: [REDO] runtime/NMT/SummarySanityCheck.java failed with "Total committed (MMMMMM) did not match the summarized committed (NNNNNN)"

Reviewed-by: gziemski, stuefe

! src/hotspot/share/nmt/mallocTracker.cpp
! src/hotspot/share/nmt/mallocTracker.hpp

Changeset: 1fde8b86
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2023-12-18 17:05:22 +0000
URL:       https://git.openjdk.org/leyden/commit/1fde8b868a0e40fb79de505106ef07e3dccbd1de

8321933: TestCDSVMCrash.java spawns two processes

Reviewed-by: ccheung, iklam

! test/hotspot/jtreg/runtime/cds/TestCDSVMCrash.java

Changeset: 4f3de096
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2023-12-18 17:56:07 +0000
URL:       https://git.openjdk.org/leyden/commit/4f3de09672d203a0182f330645962c3d08e5e206

8321940: Improve CDSHeapVerifier in handling of interned strings

Reviewed-by: ccheung, matsaave

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

Changeset: b98d13fc
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2023-12-18 18:10:34 +0000
URL:       https://git.openjdk.org/leyden/commit/b98d13fc3c7f6747d9201eb884cf9d3181671ccb

8259637: java.io.File.getCanonicalPath() returns different values for same path

Reviewed-by: alanb

! src/java.base/unix/native/libjava/path_util.c
! test/jdk/java/io/File/GetCanonicalPath.java

Changeset: 459957f3
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2023-12-18 21:14:09 +0000
URL:       https://git.openjdk.org/leyden/commit/459957f30a6e0fe40636dd72faa3f0d86151c94f

8322062: com/sun/jdi/JdwpAllowTest.java does not performs negative testing with prefix length

Reviewed-by: cjplummer, sspitsyn

! test/jdk/com/sun/jdi/JdwpAllowTest.java

Changeset: 808a0392
Author:    William Kemper <wkemper at openjdk.org>
Committer: Y. Srinivas Ramakrishna <ysr at openjdk.org>
Date:      2023-12-19 00:09:31 +0000
URL:       https://git.openjdk.org/leyden/commit/808a03927c153581cbece93a4f5a4f8242b61ef5

8321815: Shenandoah: gc state should be synchronized to java threads only once per safepoint

Reviewed-by: kdnilsen, ysr

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp

Changeset: 59073fa3
Author:    Gui Cao <gcao at openjdk.org>
Committer: Robbin Ehn <rehn at openjdk.org>
Date:      2023-12-19 07:45:59 +0000
URL:       https://git.openjdk.org/leyden/commit/59073fa3eb7d04d9e0f08fbef70c9db6ffde296a

8322154: RISC-V: JDK-8315743 missed change in MacroAssembler::load_reserved

Reviewed-by: fyang, rehn, luhenry

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

Changeset: 76637c53
Author:    Jatin Bhateja <jbhateja at openjdk.org>
Date:      2023-12-19 07:51:52 +0000
URL:       https://git.openjdk.org/leyden/commit/76637c53c56d39cc534ecaa9e9ff55413173b15c

8321648: Integral gather optimized mask computation.

Reviewed-by: thartmann, sviswanathan

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/x86.ad

Changeset: 7b4d62c7
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2023-12-19 08:39:45 +0000
URL:       https://git.openjdk.org/leyden/commit/7b4d62c794940f5ce45eb4431291bbb5467ce2de

8322300: Remove redundant arg in PSAdaptiveSizePolicy::adjust_promo_for_pause_time

Reviewed-by: tschatzl

! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp
! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.hpp

Changeset: fff2e580
Author:    Hamlin Li <mli at openjdk.org>
Date:      2023-12-19 08:45:15 +0000
URL:       https://git.openjdk.org/leyden/commit/fff2e580cdab90ea828c1c300440471981646c51

8322195: RISC-V: Minor improvement of MD5 instrinsic

Reviewed-by: luhenry, fyang

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

Changeset: 0ad6c9e3
Author:    Guoxiong Li <gli at openjdk.org>
Date:      2023-12-19 10:39:37 +0000
URL:       https://git.openjdk.org/leyden/commit/0ad6c9e3d91005c0cc3a26d5391444c3dcd8ba5d

8322255: Generational ZGC: ZPageSizeMedium should be set before MaxTenuringThreshold

Reviewed-by: tschatzl, eosterlund

! src/hotspot/share/gc/z/zArguments.cpp
! src/hotspot/share/gc/z/zInitialize.cpp

Changeset: ac968c36
Author:    Quan Anh Mai <qamai at openjdk.org>
Date:      2023-12-19 10:39:50 +0000
URL:       https://git.openjdk.org/leyden/commit/ac968c36d7cc2e13270d28c9310178f6b654d7dc

8319451: PhaseIdealLoop::conditional_move is too conservative

Reviewed-by: redestad, thartmann, kvn

! src/hotspot/share/opto/loopopts.cpp
+ test/micro/org/openjdk/bench/vm/compiler/CMove.java

Changeset: be49dabd
Author:    Erik ?sterlund <eosterlund at openjdk.org>
Date:      2023-12-19 13:49:01 +0000
URL:       https://git.openjdk.org/leyden/commit/be49dabd0d7e1cd270399849e5353bf33361c4c5

8321619: Generational ZGC: ZColorStoreGoodOopClosure is only valid for young objects

Reviewed-by: stefank, sjohanss

! src/hotspot/share/gc/z/zBarrierSet.cpp
! src/hotspot/share/gc/z/zBarrierSet.hpp
! src/hotspot/share/gc/z/zBarrierSet.inline.hpp

Changeset: 3bc5679c
Author:    Frederic Thevenet <fthevenet at openjdk.org>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2023-12-19 13:54:49 +0000
URL:       https://git.openjdk.org/leyden/commit/3bc5679cab03936005be02e7b8140d549396d5e2

8322309: Fix an inconsistancy in spacing style in spec.gmk.template

Reviewed-by: sgehwolf, erikj

! make/autoconf/spec.gmk.template

Changeset: 6313223b
Author:    Ludovic Henry <luhenry at openjdk.org>
Date:      2023-12-19 14:15:24 +0000
URL:       https://git.openjdk.org/leyden/commit/6313223bcd525aabf180813af76d500cf60893d3

8315856: RISC-V: Use Zacas extension for cmpxchg

Reviewed-by: rehn, fyang

! src/hotspot/cpu/riscv/assembler_riscv.hpp
! 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/vm_version_riscv.hpp

Changeset: 0f8e4e0a
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2023-12-19 17:26:55 +0000
URL:       https://git.openjdk.org/leyden/commit/0f8e4e0a81257c678e948c341a241dc0b810494f

8311218: fatal error: stuck in JvmtiVTMSTransitionDisabler::VTMS_transition_disable

Reviewed-by: lmesnik, alanb

! make/data/hotspot-symbols/symbols-unix
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/include/jvm.h
! 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/prims/jvm.cpp
! src/hotspot/share/runtime/handshake.cpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/java.base/share/classes/java/lang/VirtualThread.java
! src/java.base/share/native/libjava/VirtualThread.c
+ test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java

Changeset: 51be857f
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2023-12-19 18:27:06 +0000
URL:       https://git.openjdk.org/leyden/commit/51be857f3cafa23eb7cd73e5fe3db17e6d01684c

8322166: Files.isReadable/isWritable/isExecutable expensive when file does not exist

Reviewed-by: alanb

! src/java.base/share/classes/java/nio/file/Files.java
! src/java.base/share/classes/sun/nio/fs/AbstractFileSystemProvider.java
! src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java
! src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java
! src/java.base/unix/classes/sun/nio/fs/UnixNativeDispatcher.java
! src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c

Changeset: 97db6709
Author:    Guoxiong Li <gli at openjdk.org>
Date:      2023-12-20 03:58:12 +0000
URL:       https://git.openjdk.org/leyden/commit/97db670956d83749ec3fe1485bacd046662c6856

8321688: Build on linux with GCC 7.5.0 fails after 8319577

Reviewed-by: kbarrett, sviswanathan

! src/java.base/linux/native/libsimdsort/simdsort-support.hpp

Changeset: f7dc257a
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2023-12-20 05:50:45 +0000
URL:       https://git.openjdk.org/leyden/commit/f7dc257a206d3104d6d24c2079ef1fe349368c49

8322321: Add man page doc for -XX:+VerifySharedSpaces

Reviewed-by: dholmes, ccheung

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

Changeset: 7db69e6a
Author:    bobpengxie <bobpengxie at tencent.com>
Committer: Jie Fu <jiefu at openjdk.org>
Date:      2023-12-20 07:46:11 +0000
URL:       https://git.openjdk.org/leyden/commit/7db69e6a1292829b13da0c3c2b37c8758df94932

8322513: Build failure with minimal

Reviewed-by: dholmes, rehn

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

Changeset: 2f917bff
Author:    Goetz Lindenmaier <goetz at openjdk.org>
Date:      2023-12-20 08:01:08 +0000
URL:       https://git.openjdk.org/leyden/commit/2f917bff5cbb71dccd70960f563ca1a05d109fda

8322417: Console read line with zero out should zero out when throwing exception

Reviewed-by: mbaesken, stuefe, naoto

! src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java

Changeset: 5fcac7c8
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2023-12-20 09:41:24 +0000
URL:       https://git.openjdk.org/leyden/commit/5fcac7c846b5f1716417df3682b73738c3196030

8322364: Parallel: Remove unused SizePolicyTrueValues enum members

Reviewed-by: tschatzl

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

Changeset: 14dab319
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2023-12-20 09:41:33 +0000
URL:       https://git.openjdk.org/leyden/commit/14dab319a8d401860f0232515e412d7f29dc6564

8322377: Parallel: Remove unused arg in adjust_promo_for_pause_time and adjust_eden_for_pause_time

Reviewed-by: tschatzl

! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp
! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.hpp

Changeset: 424c58f3
Author:    Weijun Wang <weijun at openjdk.org>
Date:      2023-12-20 15:45:33 +0000
URL:       https://git.openjdk.org/leyden/commit/424c58f3e94927b68329510e38bf5621f6f6e1a1

8187634: keystore.getCertificateAlias(cert) returns original alias, inconsistent with fix of JDK-6483657

Reviewed-by: mullan

! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CKeyStore.java
+ test/jdk/sun/security/mscapi/DupAlias.java

Changeset: e0bad515
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2023-12-20 15:56:50 +0000
URL:       https://git.openjdk.org/leyden/commit/e0bad5153be72df49cac9bf8914ff2b2c7244454

8322543: Parallel: Remove unused _major_pause_old_slope_counter

Reviewed-by: tschatzl

! src/hotspot/share/gc/parallel/gcAdaptivePolicyCounters.hpp

Changeset: 2d609557
Author:    Markus KARG <markus at headcrashing.eu>
Committer: Brian Burkhalter <bpb at openjdk.org>
Date:      2023-12-20 17:00:44 +0000
URL:       https://git.openjdk.org/leyden/commit/2d609557ffe8e15ab81fb51dce90e40780598371

8322141: SequenceInputStream.transferTo should not return as soon as Long.MAX_VALUE bytes have been transferred

Reviewed-by: vsitnikov, bpb, jpai

! src/java.base/share/classes/java/io/SequenceInputStream.java
! test/jdk/java/io/SequenceInputStream/TransferTo.java

Changeset: e2042421
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2023-12-20 17:32:23 +0000
URL:       https://git.openjdk.org/leyden/commit/e2042421187dafc1aea75ffe15caf8beb824205b

8321017: Record in JFR that IEEE rounding mode was corrupted by loading a library

Reviewed-by: stuefe, jbechberger

! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/bsd/os_bsd.hpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/share/jfr/metadata/metadata.xml
! src/hotspot/share/jfr/support/jfrNativeLibraryLoadEvent.cpp
! src/hotspot/share/jfr/support/jfrNativeLibraryLoadEvent.hpp

Changeset: f6fe39ff
Author:    Sean Coffey <coffeys at openjdk.org>
Date:      2023-12-20 22:03:10 +0000
URL:       https://git.openjdk.org/leyden/commit/f6fe39ff1168d27f4d0ea3e4c7f3f17ecae9e1ab

8322078: ZipSourceCache.testKeySourceMapping() test fails with The process cannot access the file because it is being used by another process

Reviewed-by: lancea

! test/jdk/java/util/zip/ZipFile/ZipSourceCache.java

Changeset: e8768ae0
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2023-12-21 01:28:48 +0000
URL:       https://git.openjdk.org/leyden/commit/e8768ae08dbee9c3e1ed01934142c03ffad5f349

8321972: test runtime/Unsafe/InternalErrorTest.java timeout on linux-riscv64 platform

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

! src/hotspot/cpu/riscv/assembler_riscv.hpp
! src/hotspot/os_cpu/linux_riscv/os_linux_riscv.cpp

Changeset: 05745e3f
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2023-12-21 09:17:31 +0000
URL:       https://git.openjdk.org/leyden/commit/05745e3f1d56f71d7647e81fa5933c9f4ed18430

8319548: Unexpected internal name for Filler array klass causes error in VisualVM

Co-authored-by: Tom?? H?rka <tomas.hurka at oracle.com>
Reviewed-by: ayang, dholmes

! src/hotspot/share/memory/universe.cpp
! test/hotspot/jtreg/gc/TestFillerObjectInstantiation.java

Changeset: aff659aa
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2023-12-21 10:07:31 +0000
URL:       https://git.openjdk.org/leyden/commit/aff659aaf7c73ff8eb903fd3e426e1b42ea6d95a

8322538: remove fatal from JVM_VirtualThread functions for !INCLUDE_JVMTI

Reviewed-by: dholmes, alanb

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

Changeset: 6de23bf3
Author:    Goetz Lindenmaier <goetz at openjdk.org>
Date:      2023-12-21 11:40:30 +0000
URL:       https://git.openjdk.org/leyden/commit/6de23bf36e125c77f6f17235d81a33ff25b942fe

8322418: Problem list gc/TestAllocHumongousFragment.java subtests for 8298781

Reviewed-by: mbaesken

! test/hotspot/jtreg/ProblemList.txt

Changeset: 1802601a
Author:    Lei Zaakjyu <lizbing07734 at icloud.com>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
Date:      2023-12-21 15:20:01 +0000
URL:       https://git.openjdk.org/leyden/commit/1802601a12c72bcc44496ba2eb2c8a40a0603345

8293623: Simplify G1ConcurrentRefineThreadControl

Reviewed-by: kbarrett, tschatzl

! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp
! src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp

Changeset: 3b908c47
Author:    Evgeny Astigeevich <eastigeevich at openjdk.org>
Date:      2023-12-21 18:51:50 +0000
URL:       https://git.openjdk.org/leyden/commit/3b908c478186cbfd9d449422aaa5adacd5e5c2d4

8319795: Static huge pages are not used for CodeCache

Reviewed-by: shade, simonis, thartmann, stuefe

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/runtime/os.hpp
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/compiler/codecache/CheckLargePages.java

Changeset: 84c23792
Author:    Raphael Mosaner <raphael.m.mosaner at oracle.com>
Committer: Tom Rodriguez <never at openjdk.org>
Date:      2023-12-21 19:22:48 +0000
URL:       https://git.openjdk.org/leyden/commit/84c23792856c5c2374963d78a7a734a467bbb79b

8320139: [JVMCI] VmObjectAlloc is not generated by intrinsics methods which allocate objects

Reviewed-by: never, dnsimon

! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp

Changeset: c53f845e
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2023-12-22 07:58:09 +0000
URL:       https://git.openjdk.org/leyden/commit/c53f845ec9943c1bd59a7757cce431217aac2bdc

8322539: Parallel: Remove duplicated methods in PSAdaptiveSizePolicy

Reviewed-by: tschatzl, kbarrett

! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp
! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.hpp
! src/hotspot/share/gc/shared/adaptiveSizePolicy.hpp

Changeset: dce7a573
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2023-12-22 13:25:39 +0000
URL:       https://git.openjdk.org/leyden/commit/dce7a5732e69b6d29f75b98f6cf58a567d353a59

8321683: Tests fail with AssertionError in RangeWithPageSize

Reviewed-by: stuefe, mbaesken

! test/hotspot/jtreg/runtime/os/TestTracePageSizes.java

Changeset: 12308533
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2023-12-22 13:30:05 +0000
URL:       https://git.openjdk.org/leyden/commit/1230853343c38787c90820d19d0626f0c37540dc

8322163: runtime/Unsafe/InternalErrorTest.java fails on Alpine after JDK-8320886

Reviewed-by: mdoerr, clanger

! src/hotspot/share/utilities/copy.cpp

Changeset: 93fedc12
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Date:      2023-12-22 16:09:22 +0000
URL:       https://git.openjdk.org/leyden/commit/93fedc12db95d1e61c17537652cac3d4e27ddf2c

8321802: (zipfs) Add validation of incorrect LOC signature in ZipFileSystem

Reviewed-by: alanb, lancea

! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
! test/jdk/jdk/nio/zipfs/CorruptedZipFilesTest.java

Changeset: f695ca58
Author:    Rajat Mahajan <rmahajan at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
Date:      2023-12-22 20:16:45 +0000
URL:       https://git.openjdk.org/leyden/commit/f695ca588453265d6ad791c6a396197e8a53ba39

8321151: JDK-8294427 breaks Windows L&F on all older Windows versions

Reviewed-by: aivanov, achung

! src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp

Changeset: 7263e25d
Author:    Joshua Cao <joshcao at amazon.com>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2023-12-22 21:08:45 +0000
URL:       https://git.openjdk.org/leyden/commit/7263e25d9b69d67697992a284c75454c479b6ec3

8322490: cleanup CastNode construction

Reviewed-by: chagedorn, phh

! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/castnode.cpp
! src/hotspot/share/opto/castnode.hpp
! src/hotspot/share/opto/cfgnode.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopTransform.cpp
! src/hotspot/share/opto/parse2.cpp
! src/hotspot/share/opto/vector.cpp

Changeset: 28c82bf1
Author:    Jie Fu <jiefu at openjdk.org>
Date:      2023-12-22 23:53:42 +0000
URL:       https://git.openjdk.org/leyden/commit/28c82bf18d85be00bea45daf81c6a9d665ac676f

8322661: Build broken due to missing jvmtiExport.hpp after JDK-8320139

Reviewed-by: chagedorn, never

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

Changeset: 4fc6b0ff
Author:    Eamonn McManus <emcmanus at openjdk.org>
Date:      2023-12-23 22:53:23 +0000
URL:       https://git.openjdk.org/leyden/commit/4fc6b0ffa4f771991a5ebd982b5133d2e364fdae

8068958: Timestamp.from(Instant) should throw when conversion is not possible

Reviewed-by: rgiulietti, rriggs

! src/java.sql/share/classes/java/sql/Timestamp.java
! test/jdk/java/sql/testng/test/sql/TimestampTests.java

Changeset: 2a59243c
Author:    John Jiang <jjiang at openjdk.org>
Date:      2023-12-27 02:31:50 +0000
URL:       https://git.openjdk.org/leyden/commit/2a59243cbaf3e7d5d1bfc9f247d28bc648687ea5

8322734: A redundant return in method padWithLen

Reviewed-by: jiefu

! src/java.base/share/classes/com/sun/crypto/provider/ISO10126Padding.java
! src/java.base/share/classes/com/sun/crypto/provider/PKCS5Padding.java

Changeset: 19147f32
Author:    Olga Mikhaltsova <omikhaltcova at openjdk.org>
Committer: Vladimir Kempik <vkempik at openjdk.org>
Date:      2023-12-29 18:33:43 +0000
URL:       https://git.openjdk.org/leyden/commit/19147f326c6b0e78fe72f9a7e7100047f16a0921

8318158: RISC-V: implement roundD/roundF intrinsics

Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
Reviewed-by: luhenry, fyang, mli

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

Changeset: 32d80e2c
Author:    Christoph Langer <clanger at openjdk.org>
Date:      2023-12-29 21:49:06 +0000
URL:       https://git.openjdk.org/leyden/commit/32d80e2caf6063b58128bd5f3dc87b276f3bd0cb

8322772: Clean up code after JDK-8322417

Reviewed-by: mdoerr, goetz, mbaesken, vtewari

! src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java

Changeset: 518ec971
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2023-12-31 17:26:57 +0000
URL:       https://git.openjdk.org/leyden/commit/518ec9711411e6825668f72503a2e96824cd37ba

8322747: StringTable should be AllStatic

Reviewed-by: eosterlund

! src/hotspot/share/classfile/stringTable.hpp

Changeset: 7c1d481d
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-01-02 03:06:13 +0000
URL:       https://git.openjdk.org/leyden/commit/7c1d481d6ddeb67118abbdc909884f4793343fee

8322765: Eliminate -Wparentheses warnings in runtime code

Reviewed-by: dholmes

! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/interpreter/bytecodes.cpp
! src/hotspot/share/oops/constantPool.hpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/utilities/utf8.cpp

Changeset: be0e1c7b
Author:    Lei Zaakjyu <lizbing07734 at icloud.com>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-01-02 08:45:55 +0000
URL:       https://git.openjdk.org/leyden/commit/be0e1c7b14c919d26f9e80fe68ad8296aeed3de7

8297573: Parallel: Rename do_oop_nv to do_oop_work in subclasses of OopClosure

Reviewed-by: ayang, gli

! src/hotspot/share/gc/parallel/psCompactionManager.inline.hpp
! src/hotspot/share/gc/parallel/psParallelCompact.inline.hpp
! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp

Changeset: 5852f3ea
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
Date:      2024-01-02 10:13:37 +0000
URL:       https://git.openjdk.org/leyden/commit/5852f3eafe4509a064c727371962ff249886e115

8322027: One XMLStreamException constructor fails to initialize cause

Reviewed-by: joehw, jpai

! src/java.xml/share/classes/javax/xml/stream/XMLStreamException.java
+ test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamExceptionTest/ExceptionCauseTest.java

Changeset: d786c495
Author:    Guoxiong Li <gli at openjdk.org>
Date:      2024-01-02 10:34:25 +0000
URL:       https://git.openjdk.org/leyden/commit/d786c495253d2ad85741a05639c0c14a967d872f

8322751: ZGC: Fix comments about marking roots

Reviewed-by: eosterlund

! src/hotspot/share/gc/x/xHeap.cpp
! src/hotspot/share/gc/z/zGeneration.cpp

Changeset: d4fb3088
Author:    ANUPAM DEV <anupam.dev at oracle.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
Date:      2024-01-02 11:10:15 +0000
URL:       https://git.openjdk.org/leyden/commit/d4fb30885b007baab243536458a54b6ade610218

8317846: Typo in API documentation of classes IdentityHashMap

Reviewed-by: mli, jpai

! src/java.base/share/classes/java/util/IdentityHashMap.java

Changeset: 7455b1b5
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-01-02 11:15:12 +0000
URL:       https://git.openjdk.org/leyden/commit/7455b1b527568aff5b1c16a29fd80b05260c0fad

8322159: ThisEscapeAnalyzer crashes for erroneous code

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
! test/langtools/tools/javac/recovery/AttrRecovery.java

Changeset: 04c7db47
Author:    Per Minborg <pminborg at gmail.com>
Date:      2024-01-02 13:31:47 +0000
URL:       https://git.openjdk.org/leyden/commit/04c7db472699f9984eed7a88d980b22f7e0db51e

Merge branch 'master' into computed-constants


Changeset: 0586a45f
Author:    Per Minborg <pminborg at gmail.com>
Date:      2024-01-05 15:48:42 +0000
URL:       https://git.openjdk.org/leyden/commit/0586a45f2d71ddd257d77941481f40825f7d739c

Add method, rename Constant and simplify

! src/java.base/share/classes/java/lang/ComputedConstant.java
- src/java.base/share/classes/java/lang/Constant.java
+ src/java.base/share/classes/java/lang/SettableConstant.java
! src/java.base/share/classes/jdk/internal/constant/AbstractComputedConstant.java
! src/java.base/share/classes/jdk/internal/constant/ConstantUtil.java
+ src/java.base/share/classes/jdk/internal/constant/IntSettableConstant.java
- src/java.base/share/classes/jdk/internal/constant/StandardConstant.java
+ src/java.base/share/classes/jdk/internal/constant/StandardSettableConstant.java
- test/jdk/java/lang/ComputedConstant/BasicComputedConstant2Test.java
! test/jdk/java/lang/ComputedConstant/BasicComputedConstantTest.java
- test/jdk/java/lang/ComputedConstant/ConstantTest.java
+ test/jdk/java/lang/ComputedConstant/SettableConstantTest.java


From duke at openjdk.org  Fri Jan  5 15:14:43 2024
From: duke at openjdk.org (duke)
Date: Fri, 5 Jan 2024 15:14:43 GMT
Subject: git: openjdk/leyden: computed-constants: Remove CC2
Message-ID: <e8e62a5a-153c-424e-aa12-0d2629f4e51e@openjdk.org>

Changeset: 4fef1615
Author:    Per Minborg <pminborg at gmail.com>
Date:      2024-01-05 16:11:51 +0000
URL:       https://git.openjdk.org/leyden/commit/4fef1615c41069628d422f0fc309ad160b8ddf8d

Remove CC2

- src/java.base/share/classes/java/lang/ComputedConstant2.java


From duke at openjdk.org  Mon Jan  8 10:27:20 2024
From: duke at openjdk.org (duke)
Date: Mon, 8 Jan 2024 10:27:20 GMT
Subject: git: openjdk/leyden: computed-constants: 2 new changesets
Message-ID: <7d52e74e-7da5-4161-9798-db3321f7d971@openjdk.org>

Changeset: a0c978fe
Author:    Per Minborg <pminborg at gmail.com>
Date:      2024-01-08 09:29:17 +0000
URL:       https://git.openjdk.org/leyden/commit/a0c978fefc3e7ef27c3ae2df9f9abb494d0e5172

Add storage type for some factories

! src/java.base/share/classes/java/lang/ComputedConstant.java
! src/java.base/share/classes/java/lang/SettableConstant.java
! src/java.base/share/classes/java/lang/snippet-files/ComputedConstantSnippets.java
! test/jdk/java/lang/ComputedConstant/SettableConstantTest.java

Changeset: 722138e3
Author:    Per Minborg <pminborg at gmail.com>
Date:      2024-01-08 11:25:51 +0000
URL:       https://git.openjdk.org/leyden/commit/722138e3122e7f8c77957fbcdd2dbe729cda22fd

Add a CC variant using a class as supplier

! src/java.base/share/classes/java/lang/ComputedConstant.java
! src/java.base/share/classes/java/lang/SettableConstant.java
! src/java.base/share/classes/java/lang/snippet-files/ComputedConstantSnippets.java
! src/java.base/share/classes/jdk/internal/constant/AbstractComputedConstant.java
+ src/java.base/share/classes/jdk/internal/constant/ClassProvidedComputedConstant.java
! test/jdk/java/lang/ComputedConstant/BasicComputedConstantTest.java
! test/jdk/java/lang/ComputedConstant/BasicListOfComputedConstantTest.java


From duke at openjdk.org  Mon Jan  8 10:32:19 2024
From: duke at openjdk.org (duke)
Date: Mon, 8 Jan 2024 10:32:19 GMT
Subject: git: openjdk/leyden: computed-constants: Pretty
Message-ID: <a992f4d3-f15b-45ea-975b-e1a56d3ccede@openjdk.org>

Changeset: faf1fe03
Author:    Per Minborg <pminborg at gmail.com>
Date:      2024-01-08 11:29:40 +0000
URL:       https://git.openjdk.org/leyden/commit/faf1fe03451d73c18a691b1095d6e3730f049e96

Pretty

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


From duke at openjdk.org  Mon Jan  8 14:59:54 2024
From: duke at openjdk.org (duke)
Date: Mon, 8 Jan 2024 14:59:54 GMT
Subject: git: openjdk/leyden: computed-constants: Add exploded sandbox
Message-ID: <a79e38ce-adaa-4c13-b096-aeaa9051dd6c@openjdk.org>

Changeset: 2e162296
Author:    Per Minborg <pminborg at gmail.com>
Date:      2024-01-08 15:59:00 +0000
URL:       https://git.openjdk.org/leyden/commit/2e1622968cfad4f101c42f0964e4ac4f5adfe9bc

Add exploded sandbox

+ test/jdk/java/lang/ComputedConstant/SandboxTest.java


From duke at openjdk.org  Tue Jan  9 22:08:19 2024
From: duke at openjdk.org (duke)
Date: Tue, 9 Jan 2024 22:08:19 GMT
Subject: git: openjdk/leyden: premain: preimage: Don't tweak execution mode
Message-ID: <0c0f7fbe-730f-493c-9945-13372bb62b6c@openjdk.org>

Changeset: 448178f4
Author:    Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
Date:      2024-01-09 14:06:40 +0000
URL:       https://git.openjdk.org/leyden/commit/448178f4eab3b757e302b1b3732b6774e3107457

preimage: Don't tweak execution mode

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


From duke at openjdk.org  Tue Jan  9 23:56:08 2024
From: duke at openjdk.org (duke)
Date: Tue, 9 Jan 2024 23:56:08 GMT
Subject: git: openjdk/leyden: premain: Remove CompileTrainingData::_top_method
Message-ID: <41660d85-20ec-49cc-a87e-e7da6af89f04@openjdk.org>

Changeset: 3f419ca9
Author:    Igor Veresov <igor.veresov at oracle.com>
Date:      2024-01-09 15:54:31 +0000
URL:       https://git.openjdk.org/leyden/commit/3f419ca9ce3412c4a21a7574f853aca29973bb5a

Remove CompileTrainingData::_top_method

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


From duke at openjdk.org  Wed Jan 10 00:26:41 2024
From: duke at openjdk.org (duke)
Date: Wed, 10 Jan 2024 00:26:41 GMT
Subject: git: openjdk/leyden: premain: Don't tweak execution mode when dumping
 final static archive
Message-ID: <a240b390-66ae-4ab6-b87a-a8d5f0a47410@openjdk.org>

Changeset: a1f8fada
Author:    Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
Date:      2024-01-09 16:24:56 +0000
URL:       https://git.openjdk.org/leyden/commit/a1f8fada623f288e405a6dd8c771a5530607fbb2

Don't tweak execution mode when dumping final static archive

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


From john.r.rose at oracle.com  Thu Jan 11 22:15:06 2024
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 11 Jan 2024 14:15:06 -0800
Subject: premain: negative lookup cache for class loaders
In-Reply-To: <CAKt0pyTaEkJe60FxsdPLdejOVp=odg--QOL7q3TYnKyWjDVSMw@mail.gmail.com>
References: <CAKt0pyTaEkJe60FxsdPLdejOVp=odg--QOL7q3TYnKyWjDVSMw@mail.gmail.com>
Message-ID: <66AA883C-EF83-46FE-82E7-D559B95E3657@oracle.com>

(I?m putting in email something we discussed on a zoom call.)

On the premain project, we are learning to perform special optimizations 
that depend on ?well behaved? class loaders, because they are simply 
front-ends to declarative information like the class path.  These 
optimizations shift work into a training run, storing resulting states 
into a CDS archive, and then adopting those states into a deployed 
application, quickly, as it starts up.

(?But what about user-defined loaders?  But why do we have to use 
CDS?? ? See below for comments on these two side issues.)

Ashutosh, you and your team have mentioned that there are tens of 
milliseconds (several percentage points of time) consumed during startup 
of some workloads by *failed* lookups. A logging framework may be 
querying for code resources and falling back somehow if they fail to 
load.  The code probably has a try/catch that processes 
`ClassNotFoundException` or the like.

We know that *successful* lookups go fast the second time because the VM 
caches the result in a central system dictionary.  And, CDS technology 
makes successful lookups go fast the *first time*, if the lookup was 
performed in a training run and the resulting state stored in a CDS 
archive.  (Those who watch our premain branch will see that there is 
lots of low-hanging fruit in CDS, that we are only beginning to enjoy.)

But, a *failed* lookup is not recorded anywhere.  So every distinct 
lookup must start again from first principles and fail all over again.  
For some workloads this costs a small but measurable percentage of 
startup time.

The story is different for the local `CONSTANT_Class` entries in any 
given classfile:  The JVMS mandates that both successful and failed 
lookups are recorded on the first attempt (per CP entry per se, not 
globally and not per class).  Global usage includes both use of 
`Class.forName` and the ?back end? logic for CP entry resolution.  
CP resolution is performed at most once per CP entry, and (win or lose) 
is made sticky on the CP itself, locally.

To summarize, we can say that, for class lookup, both success and 
failure are ?sticky? locally, and success is ?sticky? globally, 
but failure is ?not sticky? globally.

The global behavior can be thought of either specific to a class loader 
(i.e., coded in JDK code) or as something in the VM or JNI code that 
works with the JDK code.  In reality it is an emergent property of a 
number of small details in both.

A *negative lookup cache* is a collection of class names (for a given 
loader) which have already failed to load.  ?Sticky failure? could 
be implemented with a negative lookup cache, either on a class loader 
(my preferred solution, I think) or else somewhere in the VM internals 
that participate in class loading paths.

The benefits are obvious: Startup could be shorter by tens of 
milliseconds.  The eliminated operations include re-creating exceptions, 
and throwing and catching them, and (maybe) uselessly re-probing the 
file system.

The risks include at least two cases.  First, a user might somehow 
contrive to extend the class path after a failure has been made sticky, 
and then the user could be disappointed when a class appears on the new 
class path components that satisfies the load.  Second, a user might 
somehow contrive to mutate an existing class path component (by writing 
a file into a directory, say), and have the same disappointment of not 
seeing the classfile get picked up on the next request.

But it seems to me that a negative lookup cache is a legitimate 
optimization *for well behaved class loaders*.  (Please check my work 
here!)  The preconditions are that the well behaved class takes its 
input from inputs that cannot be updated after the VM has started 
running.  Or, if and when those inputs are updated somehow, the negative 
cache must be invalidated, at least for classes that could possibly be 
loaded from the updated parts.  You can sometimes reason from the 
package prefix and from the class path updates that some name cannot be 
read from some class path element, just because of a missing directory.

A CDS archive records its class path, and can detect whether that class 
path reads only from an immutable backing store.  (This is a sweet spot 
for Leyden.)  If that is the case, then the CDS archive could also store 
a negative lookup cache (for each eligible class loader).  I think this 
should be done in Java code and the relevant field and its data 
special-cased to be retained via CDS.

(I mean ?special-cased? the way we already special-case some other 
selected data, like the module graph and integer box cache.  As with 
framework-defined class loaders, we may have a conversation in the 
future about letting user code into this little game as well.  But it 
has to be done in a way that does not violate any specification, which 
makes it challenging.  One step at a time.)

For immediate prototyping and testing of the concept, we don?t need to 
bring CDS into the picture.  We can just have a global flag that says 
?it is safe to use a negative lookup cache?.  But to roll out this 
optimization in a product, the flag needs to be automatically set to a 
safe value, probably by CDS at startup, based on in inspection of the 
class path settings in both training and deployment runs.  And of course 
(as a separate step) we can pre-populate the caches at CDS dump time 
(that is, after a training run), so that the deployed application can 
immediately benefit from the cache, and spend zero time exploring the 
class path for classes that are known to be missing.

BTW, I think it is just fine to throw a pre-constructed exception when 
the negative lookup cache hits, even though some users will complain 
that such exceptions are lacking meaningful messages and backtraces.  
It?s within spec.  HotSpot does this for certain ?hot throws? of 
built-in exceptions; see `GraphKit::builtin_throw`, and see also the 
tricky logic that makes failures sticky in CP entries (which edits down 
the exception information).  As a compromise, the negative lookup cache 
could store an exception object whose message is the class name (but 
with no backtrace).

There?s a another way to approach this issue, which is to index the 
class path in such a way that class loaders can respond to arbitrary 
load requests but do little or no work on failing requests.  A Bloom 
filter is sometimes used in such cases to avoid many (not all) of the 
searches.  But I think that?s overkill for the use cases we actually 
observe, which is a large number of failed lookups on a small number of 
class names.  A per-loader table mapping a name to an exception seems to 
be a good tradeoff.  And as I noted, CDS can pre-populate these things 
eventually.

Ashutosh, maybe you are interested in working on some of this? :-)

? John

P.S. If the negative lookup cache has the right ?stability? 
properties, we can even ask the JIT to think about optimizing failing 
`Class.forName` calls, by consulting the cache at compile time.  In the 
Leyden setting, some `Class.forName` calls (not all) can be 
constant-folded.  Perhaps the argument is semi-constant and can be 
profiled and speculated.  Maybe some of that pays off, or maybe not; 
probably not since the `forName` call is probably buried in a stack of 
middleware.  These are ideas for the JIT team to put on their very long 
list.

P.P.S.  Regarding the two side issues mentioned above?

We are not at all forgetting about framework-defined class loaders.  But 
for the next few months it is enough to assume that we will optimize 
only class loaders which are defined by the VM+JDK substrate.  In the 
future we will want to investigate how to make framework-defined loaders 
compatible with whatever optimizations we create for the well behaved 
JDK class loaders.  It it not yet time to discuss that in detail; it is 
time to learn the elements of our craft by working with the well behaved 
class loaders only.

The same comment applies to the observation that we might try to 
?auto-train? applications.  That is, get rid of the CDS archive, 
generated by a separate training run, and just automagically run the 
same application faster the second time, by capturing CDS-like states 
from the first run, treating it ?secretly? as a training run.  We 
know this can work well on some Java workloads.  But we also like the 
predictability and simplicity of CDS.  For HotSpot, it is not yet time 
to work on applying our learnings with CDS to the problem of 
auto-training.  I hope that time will come after we have mined out more 
of the basic potential of CDS.  For now we are working on the 
?one-step workflow?, where there is an explicit training phase that 
generates CDS.  The ?zero-step workflow? will comne in time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240111/36bdd0cd/attachment.htm>

From vladimir.x.ivanov at oracle.com  Fri Jan 12 00:39:06 2024
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 11 Jan 2024 16:39:06 -0800
Subject: premain: negative lookup cache for class loaders
In-Reply-To: <66AA883C-EF83-46FE-82E7-D559B95E3657@oracle.com>
References: <CAKt0pyTaEkJe60FxsdPLdejOVp=odg--QOL7q3TYnKyWjDVSMw@mail.gmail.com>
 <66AA883C-EF83-46FE-82E7-D559B95E3657@oracle.com>
Message-ID: <f13ae7ba-04ae-4c78-801a-55dc402c646a@oracle.com>


> We know that /successful/ lookups go fast the second time because the VM 
> caches the result in a central system dictionary. And, CDS technology 
> makes successful lookups go fast the /first time/, if the lookup was 
> performed in a training run and the resulting state stored in a CDS 
> archive. (Those who watch our premain branch will see that there is lots 
> of low-hanging fruit in CDS, that we are only beginning to enjoy.)

Even though repeated successful lookups are already fast it is still 
benefitial to optimize them. For example, class pre-loading and CP entry 
pre-resolution are implemented in premain and do give noticeable startup 
improvements.

And repeated successful lookups are common when it comes to 
Class.forName(). For example, PetClinic deployment run experiences 10k 
calls into JVM_FindClassFromCaller which cost ~20ms (measured on M1 Pro).

So, while negative lookup cache looks like the lowest hanging fruit, 
it's worth to consider positive lookup caching scenario as well.

Best regards,
Vladimir Ivanov

> But, a /failed/ lookup is not recorded anywhere. So every distinct 
> lookup must start again from first principles and fail all over again. 
> For some workloads this costs a small but measurable percentage of 
> startup time.
> 
> The story is different for the local |CONSTANT_Class| entries in any 
> given classfile: The JVMS mandates that both successful and failed 
> lookups are recorded on the first attempt (per CP entry per se, not 
> globally and not per class). Global usage includes both use of 
> |Class.forName| and the ?back end? logic for CP entry resolution. CP 
> resolution is performed at most once per CP entry, and (win or lose) is 
> made sticky on the CP itself, locally.
> 
> To summarize, we can say that, for class lookup, both success and 
> failure are ?sticky? locally, and success is ?sticky? globally, but 
> failure is ?not sticky? globally.
> 
> The global behavior can be thought of either specific to a class loader 
> (i.e., coded in JDK code) or as something in the VM or JNI code that 
> works with the JDK code. In reality it is an emergent property of a 
> number of small details in both.
> 
> A /negative lookup cache/ is a collection of class names (for a given 
> loader) which have already failed to load. ?Sticky failure? could be 
> implemented with a negative lookup cache, either on a class loader (my 
> preferred solution, I think) or else somewhere in the VM internals that 
> participate in class loading paths.
> 
> The benefits are obvious: Startup could be shorter by tens of 
> milliseconds. The eliminated operations include re-creating exceptions, 
> and throwing and catching them, and (maybe) uselessly re-probing the 
> file system.
> 
> The risks include at least two cases. First, a user might somehow 
> contrive to extend the class path after a failure has been made sticky, 
> and then the user could be disappointed when a class appears on the new 
> class path components that satisfies the load. Second, a user might 
> somehow contrive to mutate an existing class path component (by writing 
> a file into a directory, say), and have the same disappointment of not 
> seeing the classfile get picked up on the next request.
> 
> But it seems to me that a negative lookup cache is a legitimate 
> optimization /for well behaved class loaders/. (Please check my work 
> here!) The preconditions are that the well behaved class takes its input 
> from inputs that cannot be updated after the VM has started running. Or, 
> if and when those inputs are updated somehow, the negative cache must be 
> invalidated, at least for classes that could possibly be loaded from the 
> updated parts. You can sometimes reason from the package prefix and from 
> the class path updates that some name cannot be read from some class 
> path element, just because of a missing directory.
> 
> A CDS archive records its class path, and can detect whether that class 
> path reads only from an immutable backing store. (This is a sweet spot 
> for Leyden.) If that is the case, then the CDS archive could also store 
> a negative lookup cache (for each eligible class loader). I think this 
> should be done in Java code and the relevant field and its data 
> special-cased to be retained via CDS.
> 
> (I mean ?special-cased? the way we already special-case some other 
> selected data, like the module graph and integer box cache. As with 
> framework-defined class loaders, we may have a conversation in the 
> future about letting user code into this little game as well. But it has 
> to be done in a way that does not violate any specification, which makes 
> it challenging. One step at a time.)
> 
> For immediate prototyping and testing of the concept, we don?t need to 
> bring CDS into the picture. We can just have a global flag that says ?it 
> is safe to use a negative lookup cache?. But to roll out this 
> optimization in a product, the flag needs to be automatically set to a 
> safe value, probably by CDS at startup, based on in inspection of the 
> class path settings in both training and deployment runs. And of course 
> (as a separate step) we can pre-populate the caches at CDS dump time 
> (that is, after a training run), so that the deployed application can 
> immediately benefit from the cache, and spend zero time exploring the 
> class path for classes that are known to be missing.
> 
> BTW, I think it is just fine to throw a pre-constructed exception when 
> the negative lookup cache hits, even though some users will complain 
> that such exceptions are lacking meaningful messages and backtraces. 
> It?s within spec. HotSpot does this for certain ?hot throws? of built-in 
> exceptions; see |GraphKit::builtin_throw|, and see also the tricky logic 
> that makes failures sticky in CP entries (which edits down the exception 
> information). As a compromise, the negative lookup cache could store an 
> exception object whose message is the class name (but with no backtrace).
> 
> There?s a another way to approach this issue, which is to index the 
> class path in such a way that class loaders can respond to arbitrary 
> load requests but do little or no work on failing requests. A Bloom 
> filter is sometimes used in such cases to avoid many (not all) of the 
> searches. But I think that?s overkill for the use cases we actually 
> observe, which is a large number of failed lookups on a small number of 
> class names. A per-loader table mapping a name to an exception seems to 
> be a good tradeoff. And as I noted, CDS can pre-populate these things 
> eventually.
> 
> Ashutosh, maybe you are interested in working on some of this? :-)
> 
> ? John
> 
> P.S. If the negative lookup cache has the right ?stability? properties, 
> we can even ask the JIT to think about optimizing failing 
> |Class.forName| calls, by consulting the cache at compile time. In the 
> Leyden setting, some |Class.forName| calls (not all) can be 
> constant-folded. Perhaps the argument is semi-constant and can be 
> profiled and speculated. Maybe some of that pays off, or maybe not; 
> probably not since the |forName| call is probably buried in a stack of 
> middleware. These are ideas for the JIT team to put on their very long list.
> 
> P.P.S. Regarding the two side issues mentioned above?
> 
> We are not at all forgetting about framework-defined class loaders. But 
> for the next few months it is enough to assume that we will optimize 
> only class loaders which are defined by the VM+JDK substrate. In the 
> future we will want to investigate how to make framework-defined loaders 
> compatible with whatever optimizations we create for the well behaved 
> JDK class loaders. It it not yet time to discuss that in detail; it is 
> time to learn the elements of our craft by working with the well behaved 
> class loaders only.
> 
> The same comment applies to the observation that we might try to 
> ?auto-train? applications. That is, get rid of the CDS archive, 
> generated by a separate training run, and just automagically run the 
> same application faster the second time, by capturing CDS-like states 
> from the first run, treating it ?secretly? as a training run. We know 
> this can work well on some Java workloads. But we also like the 
> predictability and simplicity of CDS. For HotSpot, it is not yet time to 
> work on applying our learnings with CDS to the problem of auto-training. 
> I hope that time will come after we have mined out more of the basic 
> potential of CDS. For now we are working on the ?one-step workflow?, 
> where there is an explicit training phase that generates CDS. The 
> ?zero-step workflow? will comne in time.
> 

From asmehra at redhat.com  Fri Jan 12 20:32:28 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Fri, 12 Jan 2024 15:32:28 -0500
Subject: premain: negative lookup cache for class loaders
In-Reply-To: <f13ae7ba-04ae-4c78-801a-55dc402c646a@oracle.com>
References: <CAKt0pyTaEkJe60FxsdPLdejOVp=odg--QOL7q3TYnKyWjDVSMw@mail.gmail.com>
 <66AA883C-EF83-46FE-82E7-D559B95E3657@oracle.com>
 <f13ae7ba-04ae-4c78-801a-55dc402c646a@oracle.com>
Message-ID: <CAKt0pyRreF2JkWvRbe75OKg_jbk+5YU_4tzAPHcWN3mXkz5-xg@mail.gmail.com>

>
> Ashutosh, you and your team have mentioned that there are tens of
> milliseconds (several percentage points of time) consumed during startup of
> some workloads by *failed* lookups


While working on Vladimir's suggestion to profile JVM_FindClassFromCaller,
I realized I had made a mistake in my earlier attempt to profile the
Class.forName method.
Sadly once I fixed that bug, the time spent in failed lookups is not that
significant any more.

This is the patch
<https://github.com/ashu-mehra/leyden/commit/0bd59831b387358b60b9f38080ff09081512679a>
I have for profiling Class.forName at Java level. It shows the time spent
in Class.forName for negative lookups for app class loader.
For Quarkus app that I am using, the patch reports 11ms which is 1.4% of
the startup time (of 750 ms).
For Springboot-petclinic app the patch reports 36ms which is 1.1% of the
startup time (of 3250ms).

The other patch
<https://github.com/ashu-mehra/leyden/commit/3923adbb2a3e3291965dd5b85cb7a918db555117>
I have is for profiling JVM_FindClassFromCaller when it throws an exception
for the app classloader.
For Quarkus app the patch reports 5ms.
For Springboot-petclinic app the patch reports 25ms.

Given these numbers, @JohnR do you think it is still worth spending time on
the negative cache for the class loaders?
And sorry for reporting incorrect numbers earlier.

Thanks,
- Ashutosh Mehra


On Thu, Jan 11, 2024 at 7:39?PM Vladimir Ivanov <
vladimir.x.ivanov at oracle.com> wrote:

>
> > We know that /successful/ lookups go fast the second time because the VM
> > caches the result in a central system dictionary. And, CDS technology
> > makes successful lookups go fast the /first time/, if the lookup was
> > performed in a training run and the resulting state stored in a CDS
> > archive. (Those who watch our premain branch will see that there is lots
> > of low-hanging fruit in CDS, that we are only beginning to enjoy.)
>
> Even though repeated successful lookups are already fast it is still
> benefitial to optimize them. For example, class pre-loading and CP entry
> pre-resolution are implemented in premain and do give noticeable startup
> improvements.
>
> And repeated successful lookups are common when it comes to
> Class.forName(). For example, PetClinic deployment run experiences 10k
> calls into JVM_FindClassFromCaller which cost ~20ms (measured on M1 Pro).
>
> So, while negative lookup cache looks like the lowest hanging fruit,
> it's worth to consider positive lookup caching scenario as well.
>
> Best regards,
> Vladimir Ivanov
>
> > But, a /failed/ lookup is not recorded anywhere. So every distinct
> > lookup must start again from first principles and fail all over again.
> > For some workloads this costs a small but measurable percentage of
> > startup time.
> >
> > The story is different for the local |CONSTANT_Class| entries in any
> > given classfile: The JVMS mandates that both successful and failed
> > lookups are recorded on the first attempt (per CP entry per se, not
> > globally and not per class). Global usage includes both use of
> > |Class.forName| and the ?back end? logic for CP entry resolution. CP
> > resolution is performed at most once per CP entry, and (win or lose) is
> > made sticky on the CP itself, locally.
> >
> > To summarize, we can say that, for class lookup, both success and
> > failure are ?sticky? locally, and success is ?sticky? globally, but
> > failure is ?not sticky? globally.
> >
> > The global behavior can be thought of either specific to a class loader
> > (i.e., coded in JDK code) or as something in the VM or JNI code that
> > works with the JDK code. In reality it is an emergent property of a
> > number of small details in both.
> >
> > A /negative lookup cache/ is a collection of class names (for a given
> > loader) which have already failed to load. ?Sticky failure? could be
> > implemented with a negative lookup cache, either on a class loader (my
> > preferred solution, I think) or else somewhere in the VM internals that
> > participate in class loading paths.
> >
> > The benefits are obvious: Startup could be shorter by tens of
> > milliseconds. The eliminated operations include re-creating exceptions,
> > and throwing and catching them, and (maybe) uselessly re-probing the
> > file system.
> >
> > The risks include at least two cases. First, a user might somehow
> > contrive to extend the class path after a failure has been made sticky,
> > and then the user could be disappointed when a class appears on the new
> > class path components that satisfies the load. Second, a user might
> > somehow contrive to mutate an existing class path component (by writing
> > a file into a directory, say), and have the same disappointment of not
> > seeing the classfile get picked up on the next request.
> >
> > But it seems to me that a negative lookup cache is a legitimate
> > optimization /for well behaved class loaders/. (Please check my work
> > here!) The preconditions are that the well behaved class takes its input
> > from inputs that cannot be updated after the VM has started running. Or,
> > if and when those inputs are updated somehow, the negative cache must be
> > invalidated, at least for classes that could possibly be loaded from the
> > updated parts. You can sometimes reason from the package prefix and from
> > the class path updates that some name cannot be read from some class
> > path element, just because of a missing directory.
> >
> > A CDS archive records its class path, and can detect whether that class
> > path reads only from an immutable backing store. (This is a sweet spot
> > for Leyden.) If that is the case, then the CDS archive could also store
> > a negative lookup cache (for each eligible class loader). I think this
> > should be done in Java code and the relevant field and its data
> > special-cased to be retained via CDS.
> >
> > (I mean ?special-cased? the way we already special-case some other
> > selected data, like the module graph and integer box cache. As with
> > framework-defined class loaders, we may have a conversation in the
> > future about letting user code into this little game as well. But it has
> > to be done in a way that does not violate any specification, which makes
> > it challenging. One step at a time.)
> >
> > For immediate prototyping and testing of the concept, we don?t need to
> > bring CDS into the picture. We can just have a global flag that says ?it
> > is safe to use a negative lookup cache?. But to roll out this
> > optimization in a product, the flag needs to be automatically set to a
> > safe value, probably by CDS at startup, based on in inspection of the
> > class path settings in both training and deployment runs. And of course
> > (as a separate step) we can pre-populate the caches at CDS dump time
> > (that is, after a training run), so that the deployed application can
> > immediately benefit from the cache, and spend zero time exploring the
> > class path for classes that are known to be missing.
> >
> > BTW, I think it is just fine to throw a pre-constructed exception when
> > the negative lookup cache hits, even though some users will complain
> > that such exceptions are lacking meaningful messages and backtraces.
> > It?s within spec. HotSpot does this for certain ?hot throws? of built-in
> > exceptions; see |GraphKit::builtin_throw|, and see also the tricky logic
> > that makes failures sticky in CP entries (which edits down the exception
> > information). As a compromise, the negative lookup cache could store an
> > exception object whose message is the class name (but with no backtrace).
> >
> > There?s a another way to approach this issue, which is to index the
> > class path in such a way that class loaders can respond to arbitrary
> > load requests but do little or no work on failing requests. A Bloom
> > filter is sometimes used in such cases to avoid many (not all) of the
> > searches. But I think that?s overkill for the use cases we actually
> > observe, which is a large number of failed lookups on a small number of
> > class names. A per-loader table mapping a name to an exception seems to
> > be a good tradeoff. And as I noted, CDS can pre-populate these things
> > eventually.
> >
> > Ashutosh, maybe you are interested in working on some of this? :-)
> >
> > ? John
> >
> > P.S. If the negative lookup cache has the right ?stability? properties,
> > we can even ask the JIT to think about optimizing failing
> > |Class.forName| calls, by consulting the cache at compile time. In the
> > Leyden setting, some |Class.forName| calls (not all) can be
> > constant-folded. Perhaps the argument is semi-constant and can be
> > profiled and speculated. Maybe some of that pays off, or maybe not;
> > probably not since the |forName| call is probably buried in a stack of
> > middleware. These are ideas for the JIT team to put on their very long
> list.
> >
> > P.P.S. Regarding the two side issues mentioned above?
> >
> > We are not at all forgetting about framework-defined class loaders. But
> > for the next few months it is enough to assume that we will optimize
> > only class loaders which are defined by the VM+JDK substrate. In the
> > future we will want to investigate how to make framework-defined loaders
> > compatible with whatever optimizations we create for the well behaved
> > JDK class loaders. It it not yet time to discuss that in detail; it is
> > time to learn the elements of our craft by working with the well behaved
> > class loaders only.
> >
> > The same comment applies to the observation that we might try to
> > ?auto-train? applications. That is, get rid of the CDS archive,
> > generated by a separate training run, and just automagically run the
> > same application faster the second time, by capturing CDS-like states
> > from the first run, treating it ?secretly? as a training run. We know
> > this can work well on some Java workloads. But we also like the
> > predictability and simplicity of CDS. For HotSpot, it is not yet time to
> > work on applying our learnings with CDS to the problem of auto-training.
> > I hope that time will come after we have mined out more of the basic
> > potential of CDS. For now we are working on the ?one-step workflow?,
> > where there is an explicit training phase that generates CDS. The
> > ?zero-step workflow? will comne in time.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240112/0797731e/attachment.htm>

From duke at openjdk.org  Sat Jan 13 01:21:18 2024
From: duke at openjdk.org (duke)
Date: Sat, 13 Jan 2024 01:21:18 GMT
Subject: git: openjdk/leyden: premain: 2 new changesets
Message-ID: <69b046fe-aa75-4872-a88d-bc1e76f0b1db@openjdk.org>

Changeset: d3cf79d2
Author:    Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
Date:      2024-01-12 16:08:17 +0000
URL:       https://git.openjdk.org/leyden/commit/d3cf79d2553f589a3fde9899dd9d80fa0e452a84

preload: Link holder klass before preloading code

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

Changeset: 851add9e
Author:    Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
Date:      2024-01-12 16:09:30 +0000
URL:       https://git.openjdk.org/leyden/commit/851add9ef311ec911bcd96680b07e9c15bb3cd14

Improve precompilation in one-step training mode

! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/compiler/compileTask.hpp
! src/hotspot/share/compiler/precompiler.cpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/output.cpp


From ioi.lam at oracle.com  Tue Jan 16 04:44:15 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Mon, 15 Jan 2024 20:44:15 -0800
Subject: premain: negative lookup cache for class loaders
In-Reply-To: <CAKt0pyRreF2JkWvRbe75OKg_jbk+5YU_4tzAPHcWN3mXkz5-xg@mail.gmail.com>
References: <CAKt0pyTaEkJe60FxsdPLdejOVp=odg--QOL7q3TYnKyWjDVSMw@mail.gmail.com>
 <66AA883C-EF83-46FE-82E7-D559B95E3657@oracle.com>
 <f13ae7ba-04ae-4c78-801a-55dc402c646a@oracle.com>
 <CAKt0pyRreF2JkWvRbe75OKg_jbk+5YU_4tzAPHcWN3mXkz5-xg@mail.gmail.com>
Message-ID: <258abb90-4b7f-4a1d-af61-847d7b01a380@oracle.com>

I think it's worth experimenting and see how much saving can be achieved.

Although the current estimate may be small (11 ms out of 750 ms), it may 
be a code path that's difficult to optimize down the road.

I think we can significantly improve over the current performance by 
shifting more Java computation to build time (e.g., making a heap 
snapshot of computed constants, running <clinit> at build time, etc). We 
should understand where the frameworks are doing such negative class 
lookups, and see if they can be time shifted (or otherwise avoided).

If the answer is no, then I think it's worthwhile to implement a 
*runtime* negative lookup cache. As the overall start-up time goes down, 
the cost of negative class lookup will increase. For example, if it 
becomes 9 ms out of 250ms, then it will be more significant.

Also, are you testing with "AOT" mode for Spring Petclinic -- it's a 
special packaging mode where a lot of the symbolic information are 
resolved at build time, so perhaps it will have a much lower use of 
negative class lookup?

https://github.com/openjdk/leyden/tree/premain/test/hotspot/jtreg/premain/spring-petclinic

Thanks

- Ioi


On 1/12/24 12:32 PM, Ashutosh Mehra wrote:
>
>     Ashutosh, you and your team have mentioned that there are tens of
>     milliseconds (several percentage points of time) consumed during
>     startup of some workloads by /failed/?lookups 
>
>
> While working on Vladimir's suggestion to 
> profile?JVM_FindClassFromCaller, I realized I had made a mistake in my 
> earlier attempt to profile the Class.forName method.
> Sadly once I fixed that bug, the time spent in failed lookups is not 
> that significant any more.
>
> This is the patch 
> <https://github.com/ashu-mehra/leyden/commit/0bd59831b387358b60b9f38080ff09081512679a> 
> I have for profiling Class.forName at Java level. It shows the time 
> spent in Class.forName for negative lookups for app class loader.
> For Quarkus app that I am using, the patch reports 11ms which is 1.4% 
> of the startup time (of 750 ms).
> For Springboot-petclinic app the patch reports 36ms which is 1.1% of 
> the startup time (of 3250ms).
>
> The other patch 
> <https://github.com/ashu-mehra/leyden/commit/3923adbb2a3e3291965dd5b85cb7a918db555117> 
> I have is for profiling JVM_FindClassFromCaller when it throws an 
> exception for the app classloader.
> For Quarkus app the patch reports 5ms.
> For Springboot-petclinic app the patch reports 25ms.
>
> Given these numbers, @JohnR do you think it is still worth spending 
> time on the negative cache for the class loaders?
> And sorry for reporting incorrect numbers earlier.
>
> Thanks,
> - Ashutosh Mehra
>
>
> On Thu, Jan 11, 2024 at 7:39?PM Vladimir Ivanov 
> <vladimir.x.ivanov at oracle.com> wrote:
>
>
>     > We know that /successful/ lookups go fast the second time
>     because the VM
>     > caches the result in a central system dictionary. And, CDS
>     technology
>     > makes successful lookups go fast the /first time/, if the lookup
>     was
>     > performed in a training run and the resulting state stored in a CDS
>     > archive. (Those who watch our premain branch will see that there
>     is lots
>     > of low-hanging fruit in CDS, that we are only beginning to enjoy.)
>
>     Even though repeated successful lookups are already fast it is still
>     benefitial to optimize them. For example, class pre-loading and CP
>     entry
>     pre-resolution are implemented in premain and do give noticeable
>     startup
>     improvements.
>
>     And repeated successful lookups are common when it comes to
>     Class.forName(). For example, PetClinic deployment run experiences
>     10k
>     calls into JVM_FindClassFromCaller which cost ~20ms (measured on
>     M1 Pro).
>
>     So, while negative lookup cache looks like the lowest hanging fruit,
>     it's worth to consider positive lookup caching scenario as well.
>
>     Best regards,
>     Vladimir Ivanov
>
>     > But, a /failed/ lookup is not recorded anywhere. So every distinct
>     > lookup must start again from first principles and fail all over
>     again.
>     > For some workloads this costs a small but measurable percentage of
>     > startup time.
>     >
>     > The story is different for the local |CONSTANT_Class| entries in
>     any
>     > given classfile: The JVMS mandates that both successful and failed
>     > lookups are recorded on the first attempt (per CP entry per se, not
>     > globally and not per class). Global usage includes both use of
>     > |Class.forName| and the ?back end? logic for CP entry
>     resolution. CP
>     > resolution is performed at most once per CP entry, and (win or
>     lose) is
>     > made sticky on the CP itself, locally.
>     >
>     > To summarize, we can say that, for class lookup, both success and
>     > failure are ?sticky? locally, and success is ?sticky? globally, but
>     > failure is ?not sticky? globally.
>     >
>     > The global behavior can be thought of either specific to a class
>     loader
>     > (i.e., coded in JDK code) or as something in the VM or JNI code
>     that
>     > works with the JDK code. In reality it is an emergent property of a
>     > number of small details in both.
>     >
>     > A /negative lookup cache/ is a collection of class names (for a
>     given
>     > loader) which have already failed to load. ?Sticky failure?
>     could be
>     > implemented with a negative lookup cache, either on a class
>     loader (my
>     > preferred solution, I think) or else somewhere in the VM
>     internals that
>     > participate in class loading paths.
>     >
>     > The benefits are obvious: Startup could be shorter by tens of
>     > milliseconds. The eliminated operations include re-creating
>     exceptions,
>     > and throwing and catching them, and (maybe) uselessly re-probing
>     the
>     > file system.
>     >
>     > The risks include at least two cases. First, a user might somehow
>     > contrive to extend the class path after a failure has been made
>     sticky,
>     > and then the user could be disappointed when a class appears on
>     the new
>     > class path components that satisfies the load. Second, a user might
>     > somehow contrive to mutate an existing class path component (by
>     writing
>     > a file into a directory, say), and have the same disappointment
>     of not
>     > seeing the classfile get picked up on the next request.
>     >
>     > But it seems to me that a negative lookup cache is a legitimate
>     > optimization /for well behaved class loaders/. (Please check my
>     work
>     > here!) The preconditions are that the well behaved class takes
>     its input
>     > from inputs that cannot be updated after the VM has started
>     running. Or,
>     > if and when those inputs are updated somehow, the negative cache
>     must be
>     > invalidated, at least for classes that could possibly be loaded
>     from the
>     > updated parts. You can sometimes reason from the package prefix
>     and from
>     > the class path updates that some name cannot be read from some
>     class
>     > path element, just because of a missing directory.
>     >
>     > A CDS archive records its class path, and can detect whether
>     that class
>     > path reads only from an immutable backing store. (This is a
>     sweet spot
>     > for Leyden.) If that is the case, then the CDS archive could
>     also store
>     > a negative lookup cache (for each eligible class loader). I
>     think this
>     > should be done in Java code and the relevant field and its data
>     > special-cased to be retained via CDS.
>     >
>     > (I mean ?special-cased? the way we already special-case some other
>     > selected data, like the module graph and integer box cache. As with
>     > framework-defined class loaders, we may have a conversation in the
>     > future about letting user code into this little game as well.
>     But it has
>     > to be done in a way that does not violate any specification,
>     which makes
>     > it challenging. One step at a time.)
>     >
>     > For immediate prototyping and testing of the concept, we don?t
>     need to
>     > bring CDS into the picture. We can just have a global flag that
>     says ?it
>     > is safe to use a negative lookup cache?. But to roll out this
>     > optimization in a product, the flag needs to be automatically
>     set to a
>     > safe value, probably by CDS at startup, based on in inspection
>     of the
>     > class path settings in both training and deployment runs. And of
>     course
>     > (as a separate step) we can pre-populate the caches at CDS dump
>     time
>     > (that is, after a training run), so that the deployed
>     application can
>     > immediately benefit from the cache, and spend zero time
>     exploring the
>     > class path for classes that are known to be missing.
>     >
>     > BTW, I think it is just fine to throw a pre-constructed
>     exception when
>     > the negative lookup cache hits, even though some users will
>     complain
>     > that such exceptions are lacking meaningful messages and
>     backtraces.
>     > It?s within spec. HotSpot does this for certain ?hot throws? of
>     built-in
>     > exceptions; see |GraphKit::builtin_throw|, and see also the
>     tricky logic
>     > that makes failures sticky in CP entries (which edits down the
>     exception
>     > information). As a compromise, the negative lookup cache could
>     store an
>     > exception object whose message is the class name (but with no
>     backtrace).
>     >
>     > There?s a another way to approach this issue, which is to index the
>     > class path in such a way that class loaders can respond to
>     arbitrary
>     > load requests but do little or no work on failing requests. A Bloom
>     > filter is sometimes used in such cases to avoid many (not all)
>     of the
>     > searches. But I think that?s overkill for the use cases we actually
>     > observe, which is a large number of failed lookups on a small
>     number of
>     > class names. A per-loader table mapping a name to an exception
>     seems to
>     > be a good tradeoff. And as I noted, CDS can pre-populate these
>     things
>     > eventually.
>     >
>     > Ashutosh, maybe you are interested in working on some of this? :-)
>     >
>     > ? John
>     >
>     > P.S. If the negative lookup cache has the right ?stability?
>     properties,
>     > we can even ask the JIT to think about optimizing failing
>     > |Class.forName| calls, by consulting the cache at compile time.
>     In the
>     > Leyden setting, some |Class.forName| calls (not all) can be
>     > constant-folded. Perhaps the argument is semi-constant and can be
>     > profiled and speculated. Maybe some of that pays off, or maybe not;
>     > probably not since the |forName| call is probably buried in a
>     stack of
>     > middleware. These are ideas for the JIT team to put on their
>     very long list.
>     >
>     > P.P.S. Regarding the two side issues mentioned above?
>     >
>     > We are not at all forgetting about framework-defined class
>     loaders. But
>     > for the next few months it is enough to assume that we will
>     optimize
>     > only class loaders which are defined by the VM+JDK substrate. In
>     the
>     > future we will want to investigate how to make framework-defined
>     loaders
>     > compatible with whatever optimizations we create for the well
>     behaved
>     > JDK class loaders. It it not yet time to discuss that in detail;
>     it is
>     > time to learn the elements of our craft by working with the well
>     behaved
>     > class loaders only.
>     >
>     > The same comment applies to the observation that we might try to
>     > ?auto-train? applications. That is, get rid of the CDS archive,
>     > generated by a separate training run, and just automagically run
>     the
>     > same application faster the second time, by capturing CDS-like
>     states
>     > from the first run, treating it ?secretly? as a training run. We
>     know
>     > this can work well on some Java workloads. But we also like the
>     > predictability and simplicity of CDS. For HotSpot, it is not yet
>     time to
>     > work on applying our learnings with CDS to the problem of
>     auto-training.
>     > I hope that time will come after we have mined out more of the
>     basic
>     > potential of CDS. For now we are working on the ?one-step
>     workflow?,
>     > where there is an explicit training phase that generates CDS. The
>     > ?zero-step workflow? will comne in time.
>     >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240115/fa63d941/attachment.htm>

From duke at openjdk.org  Tue Jan 16 05:41:02 2024
From: duke at openjdk.org (duke)
Date: Tue, 16 Jan 2024 05:41:02 GMT
Subject: git: openjdk/leyden: premain: Use normal thresholds for methods
 without TD
Message-ID: <9873e750-749f-41e2-8346-ccfeeac42d4a@openjdk.org>

Changeset: ec8dd9af
Author:    Igor Veresov <igor.veresov at oracle.com>
Date:      2024-01-15 21:38:47 +0000
URL:       https://git.openjdk.org/leyden/commit/ec8dd9af2485851d2718787507e80d6a8b24959e

Use normal thresholds for methods without TD

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


From duke at openjdk.org  Tue Jan 16 06:02:43 2024
From: duke at openjdk.org (duke)
Date: Tue, 16 Jan 2024 06:02:43 GMT
Subject: git: openjdk/leyden: premain: Upgraded
 test/hotspot/jtreg/premain/spring-petclinic to 3.2.0
Message-ID: <c0a9123f-fd9d-46b4-bf43-64bd609d16fb@openjdk.org>

Changeset: 6586489a
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-01-15 22:01:16 +0000
URL:       https://git.openjdk.org/leyden/commit/6586489a58954f66138f3d8e66a66cc68e2eabc5

Upgraded test/hotspot/jtreg/premain/spring-petclinic to 3.2.0

! test/hotspot/jtreg/premain/spring-petclinic/Makefile
! test/hotspot/jtreg/premain/spring-petclinic/premain-patch.diff


From david.lloyd at redhat.com  Tue Jan 16 16:55:29 2024
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 16 Jan 2024 10:55:29 -0600
Subject: premain: negative lookup cache for class loaders
In-Reply-To: <66AA883C-EF83-46FE-82E7-D559B95E3657@oracle.com>
References: <CAKt0pyTaEkJe60FxsdPLdejOVp=odg--QOL7q3TYnKyWjDVSMw@mail.gmail.com>
 <66AA883C-EF83-46FE-82E7-D559B95E3657@oracle.com>
Message-ID: <CANghgrTGg_Yf4kF78km-k_JazJ=B7BMZM6Jn65c-NoX6A6iNqg@mail.gmail.com>

On Thu, Jan 11, 2024 at 4:15?PM John Rose <john.r.rose at oracle.com> wrote:

> [...] But, a *failed* lookup is not recorded anywhere. So every distinct
> lookup must start again from first principles and fail all over again. For
> some workloads this costs a small but measurable percentage of startup time.
>
> The story is different for the local CONSTANT_Class entries in any given
> classfile: The JVMS mandates that both successful and failed lookups are
> recorded on the first attempt (per CP entry per se, not globally and not
> per class). Global usage includes both use of Class.forName and the ?back
> end? logic for CP entry resolution. CP resolution is performed at most once
> per CP entry, and (win or lose) is made sticky on the CP itself, locally.
>
> To summarize, we can say that, for class lookup, both success and failure
> are ?sticky? locally, and success is ?sticky? globally, but failure is ?not
> sticky? globally.
>
We have implemented a negative lookup cache in the past in certain of our
middleware products' custom class loaders, and while they *can* help, I
seem to recall that we had some trouble with cache explosion in some
scenarios involving certain frameworks. We abandoned that approach quite a
long time ago though in favor of a more optimized index-by-package scheme
which ensures that all lookups, success or failure, run in (more or less)
constant time, which had essentially eliminated the issue for us for that
use case.

FWIW I do think that it could be potentially nifty to constant-fold
negative lookup cases where that is possible.


-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240116/6ba339b8/attachment.htm>

From duke at openjdk.org  Wed Jan 17 01:14:27 2024
From: duke at openjdk.org (duke)
Date: Wed, 17 Jan 2024 01:14:27 GMT
Subject: git: openjdk/leyden: premain: print timing stats in
 test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBenchApp.java
Message-ID: <4c636943-9316-40b7-bf17-6bcfd40aab50@openjdk.org>

Changeset: c21af5eb
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-01-16 17:13:29 +0000
URL:       https://git.openjdk.org/leyden/commit/c21af5eb82e6c0b0633b6761535a736d7b02fe6d

print timing stats in test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBenchApp.java

! test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBenchApp.java


From duke at openjdk.org  Wed Jan 17 04:15:31 2024
From: duke at openjdk.org (duke)
Date: Wed, 17 Jan 2024 04:15:31 GMT
Subject: git: openjdk/leyden: premain: 2 new changesets
Message-ID: <35ef3a86-e2b6-4849-9fc2-8a036f4e4107@openjdk.org>

Changeset: 96997843
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-01-16 20:10:30 +0000
URL:       https://git.openjdk.org/leyden/commit/969978431e1cf772f5fc83d6b7808620fb8042a7

updated test/hotspot/jtreg/runtime/cds/appcds/leyden/SpringPetClinic.java to use version 3.2.0

! test/hotspot/jtreg/runtime/cds/appcds/leyden/SpringPetClinic.java

Changeset: 02bc149e
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-01-16 20:13:24 +0000
URL:       https://git.openjdk.org/leyden/commit/02bc149e2e4f81cf8daf35bc9838fbaf6f213caa

updated SpringPetClinic.java jtreg test to add -Dspring.aot.enabled=true

! test/hotspot/jtreg/runtime/cds/appcds/leyden/SpringPetClinic.java


From duke at openjdk.org  Thu Jan 18 05:53:02 2024
From: duke at openjdk.org (duke)
Date: Thu, 18 Jan 2024 05:53:02 GMT
Subject: git: openjdk/leyden: premain: Refactored Leyden test supporting code
 to jdk.test.lib.cds.CDSAppTester
Message-ID: <1e91700f-c4dc-4fbd-a549-58ce6832f7df@openjdk.org>

Changeset: 59f97f7a
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-01-17 21:51:08 +0000
URL:       https://git.openjdk.org/leyden/commit/59f97f7a79e4c8dcf0e557ac97a35687c58937f4

Refactored Leyden test supporting code to jdk.test.lib.cds.CDSAppTester

+ test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBench.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBenchDynamic.java
+ test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBenchLeyden.java
+ test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBenchLeydenOldWF.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBenchStatic.java
- test/hotspot/jtreg/runtime/cds/appcds/applications/javac/JavacBenchTestBase.java
= test/hotspot/jtreg/runtime/cds/appcds/applications/spring-petclinic/SpringPetClinic.java
+ test/hotspot/jtreg/runtime/cds/appcds/applications/spring-petclinic/SpringPetClinicDynamic.java
+ test/hotspot/jtreg/runtime/cds/appcds/applications/spring-petclinic/SpringPetClinicLeyden.java
+ test/hotspot/jtreg/runtime/cds/appcds/applications/spring-petclinic/SpringPetClinicLeydenOldWF.java
+ test/hotspot/jtreg/runtime/cds/appcds/applications/spring-petclinic/SpringPetClinicStatic.java
! test/hotspot/jtreg/runtime/cds/appcds/leyden/DynamicProxyTest.java
! test/hotspot/jtreg/runtime/cds/appcds/leyden/DynamicProxyTestOldWF.java
! test/hotspot/jtreg/runtime/cds/appcds/leyden/ExcludedClasses.java
! test/hotspot/jtreg/runtime/cds/appcds/leyden/ExcludedClassesOldWF.java
! test/hotspot/jtreg/runtime/cds/appcds/leyden/LeydenHello.java
! test/hotspot/jtreg/runtime/cds/appcds/leyden/LeydenHelloOldWF.java
! test/hotspot/jtreg/runtime/cds/appcds/leyden/LeydenReflection.java
! test/hotspot/jtreg/runtime/cds/appcds/leyden/LeydenReflectionOldWF.java
- test/hotspot/jtreg/runtime/cds/appcds/leyden/SpringPetClinicOldWF.java
- test/lib/jdk/test/lib/LeydenTester.java
+ test/lib/jdk/test/lib/cds/CDSAppTester.java


From sebastien.deleuze at broadcom.com  Fri Jan 19 10:47:47 2024
From: sebastien.deleuze at broadcom.com (Sebastien Deleuze)
Date: Fri, 19 Jan 2024 11:47:47 +0100
Subject: Spring team feedback on Leyden-premain optimizations
Message-ID: <CAG5jep8o7bAOpMyQN3BPEQywNCkqPU5bKE_=nSzR=5u2uH7+_A@mail.gmail.com>

Hi,

I would like to share the Spring team feedback on Leyden-premain
optimizations.

I have updated my spring-boot-leyden-demo repository [1] to leverage the
new Leyden 1 step workflow [2] that is much simpler to use than the
previous 5 steps workflow. It is great to see that we can reuse the same
`-Dspring.context.exit=onRefresh` property introduced by Spring Framework
6.1 for Class Data Sharing [3] with this new Class Data Store arrangement.

I am not sure if all optimizations are enabled yet, but the data points on
my MacBook with Spring Petclinic are already promising, and pretty close to
what we observed with the 5 steps workflow:
 - Executable JAR: 1.55s
 - Unpacked: 1.26s
 - Unpacked + Premain: 0.80s
 - Unpacked + Premain + Spring AOT: 0.56s

A few remarks:
 - We currently observe various warnings [4]
 - We have to use `-XX:CachedCodeMaxSize` in order to have cached code
generation with the "Unpacked + Premain" variant since its generates a
cached code of 12M (more than current 10M default limit)
 - We plan to do more benchmarks on cheap production servers (1 CPU 2G RAM
and 2 CPU 4G RAM)

I have for now only measured the startup time improvements, not yet the
warm up time improvements. I would be interested to know if the Leyden
premain branch already provides warm up improvements worth benchmarking
with Spring applications.

Best regards,
S?bastien Deleuze

[1] https://github.com/sdeleuze/spring-boot-leyden-demo
[2]
https://github.com/openjdk/leyden/tree/premain/test/hotspot/jtreg/premain/javac_new_workflow
[3]
https://spring.io/blog/2023/12/04/cds-with-spring-framework-6-1/#initial-cds-support-introduced-in-spring-framework-61
[4] https://gist.github.com/sdeleuze/8d442f9e85b069be0a5b24f3454d39a8

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

From sebastien.deleuze at broadcom.com  Fri Jan 19 11:20:50 2024
From: sebastien.deleuze at broadcom.com (Sebastien Deleuze)
Date: Fri, 19 Jan 2024 12:20:50 +0100
Subject: premain: negative lookup cache for class loaders
In-Reply-To: <CANghgrTGg_Yf4kF78km-k_JazJ=B7BMZM6Jn65c-NoX6A6iNqg@mail.gmail.com>
References: <CAKt0pyTaEkJe60FxsdPLdejOVp=odg--QOL7q3TYnKyWjDVSMw@mail.gmail.com>
 <66AA883C-EF83-46FE-82E7-D559B95E3657@oracle.com>
 <CANghgrTGg_Yf4kF78km-k_JazJ=B7BMZM6Jn65c-NoX6A6iNqg@mail.gmail.com>
Message-ID: <CAG5jep-R31dELNX5mERsdkOQwCO996is7Xu3NYU+rqLeYtkS5w@mail.gmail.com>

Hi,

The startup of a Spring Boot applications involves common
auto-configuration checks which would definitely benefit from negative
lookup caching at the ClassLoader level, quickly indicating which parts of
the infrastructure are not present at runtime.
Spring AOT optimizations can precompute those checks, but involve side
effects and constraints that probably mean we won't enable them by default
for the foreseeable future. The Spring codebase also contains various class
presence checks like the ones in WebMvcConfigurationSupport [1] that will
be performed regardless of Spring AOT optimizations, with typically more
negative lookups than positive ones.

Best regards,
S?bastien Deleuze

[1]
https://github.com/spring-projects/spring-framework/blob/7e511931b305edc84eb04a219c277a6c8fdcba59/spring-webmvc/src/main/java/org/springframework/web/servlet/config/annotation/WebMvcConfigurationSupport.java#L213-L227

On Tue, Jan 16, 2024 at 5:57?PM David Lloyd <david.lloyd at redhat.com> wrote:

> On Thu, Jan 11, 2024 at 4:15?PM John Rose <john.r.rose at oracle.com> wrote:
>
>> [...] But, a *failed* lookup is not recorded anywhere. So every distinct
>> lookup must start again from first principles and fail all over again. For
>> some workloads this costs a small but measurable percentage of startup time.
>>
>> The story is different for the local CONSTANT_Class entries in any given
>> classfile: The JVMS mandates that both successful and failed lookups are
>> recorded on the first attempt (per CP entry per se, not globally and not
>> per class). Global usage includes both use of Class.forName and the
>> ?back end? logic for CP entry resolution. CP resolution is performed at
>> most once per CP entry, and (win or lose) is made sticky on the CP itself,
>> locally.
>>
>> To summarize, we can say that, for class lookup, both success and
>> failure are ?sticky? locally, and success is ?sticky? globally, but failure
>> is ?not sticky? globally.
>>
> We have implemented a negative lookup cache in the past in certain of our
> middleware products' custom class loaders, and while they *can* help, I
> seem to recall that we had some trouble with cache explosion in some
> scenarios involving certain frameworks. We abandoned that approach quite a
> long time ago though in favor of a more optimized index-by-package scheme
> which ensures that all lookups, success or failure, run in (more or less)
> constant time, which had essentially eliminated the issue for us for that
> use case.
>
> FWIW I do think that it could be potentially nifty to constant-fold
> negative lookup cases where that is possible.
>
>
> --
> - DML ? he/him
>

-- 
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/20240119/0d16d12f/attachment.htm>

From duke at openjdk.org  Mon Jan 22 21:10:19 2024
From: duke at openjdk.org (duke)
Date: Mon, 22 Jan 2024 21:10:19 GMT
Subject: git: openjdk/leyden: premain: Factor in should_delay()
Message-ID: <6d7b3cc0-b99c-4bfe-aad6-2f2059ec3a66@openjdk.org>

Changeset: e73de845
Author:    Igor Veresov <igor.veresov at oracle.com>
Date:      2024-01-22 13:08:48 +0000
URL:       https://git.openjdk.org/leyden/commit/e73de8454e5763ee2ebb451521255ed2774ea06e

Factor in should_delay()

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


From stephane.nicoll at broadcom.com  Tue Jan 23 08:39:16 2024
From: stephane.nicoll at broadcom.com (Stephane Nicoll)
Date: Tue, 23 Jan 2024 09:39:16 +0100
Subject: Statistics about CDS effectiveness
Message-ID: <CANqHJzCTNkZEPcn-equSeubYz_eMn+fVZk6jZzWWoMm3RcwCAg@mail.gmail.com>

Hey,

I hope this mailing list is the right place for this. I am working with
S?bastien Deleuze on the Spring team and we've been focusing quite a bit on
CDS lately and how it can be easily leveraged by our user base.

One thing we quickly found out was that the cache can be more or less
effective depending on the way you start the app (classloaders, non
deterministic list of jar files, etc). Initially, we were testing the
startup time and comparing when CDS wasn't enabled.

I think there must be a better way and, for the lack of finding one, I've
developed a (very) pragmatic approach of parsing the JVM logs and producing
a report[1]. The tool has improved a bit for our own use case, creating the
cache and providing a report of the warnings that were issued (to spot
packages that couldn't be managed and why).

Parsing the logs is good enough for our little testing there but we were
wondering if there was an appetite (or need) to productize this. We were
thinking that JFR events could be an option.

Thanks,
S.


[1] https://github.com/snicoll/cds-log-parser

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

From duke at openjdk.org  Tue Jan 23 21:19:13 2024
From: duke at openjdk.org (duke)
Date: Tue, 23 Jan 2024 21:19:13 GMT
Subject: git: openjdk/leyden: hermetic-java-runtime: Define
 DEF_STATIC_JNI_OnLoad in libsaproc and statically link it into bin/javastatic.
Message-ID: <82355ff6-8d8e-4935-b689-9b1dbd7d68f7@openjdk.org>

Changeset: 99317d1d
Author:    Jiangli Zhou <jianglizhou at google.com>
Date:      2024-01-23 13:16:44 +0000
URL:       https://git.openjdk.org/leyden/commit/99317d1d84b980807075fc6b74d7f534471087f2

Define DEF_STATIC_JNI_OnLoad in libsaproc and statically link it into bin/javastatic.

! make/StaticLink.gmk
! src/jdk.hotspot.agent/share/native/libsaproc/sadis.c


From duke at openjdk.org  Tue Jan 23 22:29:52 2024
From: duke at openjdk.org (duke)
Date: Tue, 23 Jan 2024 22:29:52 GMT
Subject: git: openjdk/leyden: hermetic-java-runtime: Load ZipFileSystemProvider
 using a ServiceLoader directly and create the 'jarFileSystem' using the
 ZipFileSystemProvider. This is to avoid a circular loading problem during
 early system initialization when accessing JAR packaged JDK resources
 (specifically java.security), with user provided FileSystem provider involved.
Message-ID: <dea9757f-7579-4e29-870a-5947cc6cdb5d@openjdk.org>

Changeset: 23b228ea
Author:    Jiangli Zhou <jianglizhou at google.com>
Date:      2024-01-23 14:16:23 +0000
URL:       https://git.openjdk.org/leyden/commit/23b228ea6b67b98e1fb96198b1536a51763ad374

Load ZipFileSystemProvider using a ServiceLoader directly and create the 'jarFileSystem' using the ZipFileSystemProvider. This is to avoid a circular loading problem during early system initialization when accessing JAR packaged JDK resources (specifically java.security), with user provided FileSystem provider involved.

We discussed with Alan Bateman, Ron Pressler about building the JDK resources into `modules` file. When that's done, accessing hermetic packaged JDK resources would no longer use the ZipFileSystem.

! src/java.base/share/classes/jdk/internal/misc/JavaHome.java


From vladimir.x.ivanov at oracle.com  Tue Jan 23 23:05:48 2024
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 23 Jan 2024 15:05:48 -0800
Subject: premain: negative lookup cache for class loaders
In-Reply-To: <CAG5jep-R31dELNX5mERsdkOQwCO996is7Xu3NYU+rqLeYtkS5w@mail.gmail.com>
References: <CAKt0pyTaEkJe60FxsdPLdejOVp=odg--QOL7q3TYnKyWjDVSMw@mail.gmail.com>
 <66AA883C-EF83-46FE-82E7-D559B95E3657@oracle.com>
 <CANghgrTGg_Yf4kF78km-k_JazJ=B7BMZM6Jn65c-NoX6A6iNqg@mail.gmail.com>
 <CAG5jep-R31dELNX5mERsdkOQwCO996is7Xu3NYU+rqLeYtkS5w@mail.gmail.com>
Message-ID: <c00d250b-be3d-4b79-b433-d3a473d20193@oracle.com>

Good point, Sebastien. I wasn't aware lookup caches are part of 
AOT-preprocessing Spring does.

I made a quick experiment with PetClinic and observed the following 
behavior for Class.forName [1]:

   * -Dspring.aot.enabled=false: 792 exceptions thrown (293 unique names)

   * -Dspring.aot.enabled=true:  512 exceptions thrown (141 unique names)


Speaking of requests originated in 
org/springframework/util/ClassUtils.isPresent():

   * -Dspring.aot.enabled=false: 251 exceptions thrown (151 unique names)

   * -Dspring.aot.enabled=true:   63 exceptions thrown (41 unique names)


Still, the accumulated time spent in Class.forName() hints that positive 
lookups dominate negative ones:

Baseline (23-ea):

-Dspring.aot.enabled=false:  127ms (15873 events)
-Dspring.aot.enabled=true:    78ms (10185 events)


Leyden/premain deployment run:

-Dspring.aot.enabled=false: 37ms (15859 events)
-Dspring.aot.enabled=true:  18ms (10171 events)

Best regards,
Vladimir Ivanov

[1] https://gist.github.com/iwanowww/395f1be2f4890641fbeacb35ff503b49

On 1/19/24 03:20, Sebastien Deleuze wrote:
> Hi,
> 
> The startup of a Spring Boot applications involves common 
> auto-configuration checks which would definitely benefit from negative 
> lookup caching at the ClassLoader level, quickly indicating which parts 
> of the infrastructure are not present at runtime.
> Spring AOT optimizations can precompute those checks, but involve?side 
> effects and constraints that probably mean we won't enable them by 
> default for the foreseeable future. The Spring codebase also contains 
> various class presence checks like the ones in 
> WebMvcConfigurationSupport [1] that will be performed regardless of 
> Spring AOT optimizations, with typically more negative lookups?than 
> positive ones.
> 
> Best regards,
> S?bastien Deleuze
> 
> [1] 
> https://github.com/spring-projects/spring-framework/blob/7e511931b305edc84eb04a219c277a6c8fdcba59/spring-webmvc/src/main/java/org/springframework/web/servlet/config/annotation/WebMvcConfigurationSupport.java#L213-L227 <https://github.com/spring-projects/spring-framework/blob/7e511931b305edc84eb04a219c277a6c8fdcba59/spring-webmvc/src/main/java/org/springframework/web/servlet/config/annotation/WebMvcConfigurationSupport.java#L213-L227>
> 
> On Tue, Jan 16, 2024 at 5:57?PM David Lloyd <david.lloyd at redhat.com 
> <mailto:david.lloyd at redhat.com>> wrote:
> 
>     On Thu, Jan 11, 2024 at 4:15?PM John Rose <john.r.rose at oracle.com
>     <mailto:john.r.rose at oracle.com>> wrote:
> 
>         __
> 
>         [...] But, a /failed/ lookup is not recorded anywhere. So every
>         distinct lookup must start again from first principles and fail
>         all over again. For some workloads this costs a small but
>         measurable percentage of startup time.
> 
>         The story is different for the local |CONSTANT_Class| entries in
>         any given classfile: The JVMS mandates that both successful and
>         failed lookups are recorded on the first attempt (per CP entry
>         per se, not globally and not per class). Global usage includes
>         both use of |Class.forName| and the ?back end? logic for CP
>         entry resolution. CP resolution is performed at most once per CP
>         entry, and (win or lose) is made sticky on the CP itself, locally.
> 
>         To summarize, we can say that, for class lookup, both success
>         and failure are ?sticky? locally, and success is ?sticky?
>         globally, but failure is ?not sticky? globally.
> 
>     We have implemented a negative lookup cache in the past in certain
>     of our middleware products' custom class loaders, and while they
>     *can* help, I seem to recall that we had some trouble with cache
>     explosion in some scenarios involving certain frameworks. We
>     abandoned that approach quite a long time ago though in favor of a
>     more optimized index-by-package scheme which ensures that all
>     lookups, success or failure, run in (more or less) constant time,
>     which had essentially eliminated the issue for us for that use case.
> 
>     FWIW I do think that it could be potentially nifty to constant-fold
>     negative lookup cases where that is possible.
> 
> 
>     -- 
>     - DML ? he/him
> 
> 
> 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.

From duke at openjdk.org  Tue Jan 23 23:07:27 2024
From: duke at openjdk.org (duke)
Date: Tue, 23 Jan 2024 23:07:27 GMT
Subject: git: openjdk/leyden: hermetic-java-runtime: Support accessing hermetic
 `modules` image (in host JDK only, currently) from jrtfs.
Message-ID: <3403e960-26cc-4fac-b629-854f9d53833a@openjdk.org>

Changeset: e1f35d09
Author:    Jiangli Zhou <jianglizhou at google.com>
Date:      2024-01-23 14:38:50 +0000
URL:       https://git.openjdk.org/leyden/commit/e1f35d09ace675d8ff5093885313b5067a326e6f

Support accessing hermetic `modules` image (in host JDK only, currently) from jrtfs.

- Add jdk.internal.jimage.HermeticImageHelper. This class is packaged together with the jrtfs implementation classes. This solution is suggested by Liam Miller-Cushon, to allow properly supporting different cases described below. HermeticImageHelper's hermetic states are initialized during jdk.internal.misc.JavaHome <clinit> if executed in hermetic Java mode. HermeticImageHelper is used by jdk.internal.jrtfs.SystemImage if its CodeSource is null (target JDK == current JDK).

- Explicitly initialize jdk.internal.misc.JavaHome during VM initialization. This provides better control of initialization order related to JavaHome.

Discussed the approach (on the high-level) and different use cases with Alan Bateman, Liam Miller-Cushon, Ron Pressler and Severin Gehwolf. Following are the different cases:

Case 1 (new case): supported by this PR
- Host JDK = Target JDK
- Tool (host JDK) executes in hermetic mode

Case 2 (existing)
- Host JDK = Target JDK
- Tool (host JDK) executes non-hermetic

Case 3 (new case): not yet supported
- Host JDK != Target JDK
- Tool (host JDK) executes in hermetic mode
- Target JDK hermetic packaged

Case 4 (new case): works with existing OpenJDK jrtfs implementation
- Host JDK != Target JDK
- Tool (host JDK) executes in hermetic mode
- Target JDK not hermetic packaged

Case 5 (new case): not yet supported
- Host JDK != Target JDK
- Tool (host JDK) executes non-hermetic
- Tool (host JDK) executes in hermetic mode

Case 6 (existing)
- Host JDK != Target JDK
- Tool (host JDK) executes non-hermetic
- Target JDK not hermetic packaged

Case 7 (existing)
- Host JDK != Target JDK
- Tool runs on an older JDK version without hermetic support

! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/runtime/threads.cpp
! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java
+ src/java.base/share/classes/jdk/internal/jimage/HermeticImageHelper.java
! src/java.base/share/classes/jdk/internal/jrtfs/SystemImage.java
! src/java.base/share/classes/jdk/internal/misc/JavaHome.java


From ioi.lam at oracle.com  Wed Jan 24 13:23:16 2024
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 24 Jan 2024 05:23:16 -0800
Subject: Statistics about CDS effectiveness
In-Reply-To: <CANqHJzCTNkZEPcn-equSeubYz_eMn+fVZk6jZzWWoMm3RcwCAg@mail.gmail.com>
References: <CANqHJzCTNkZEPcn-equSeubYz_eMn+fVZk6jZzWWoMm3RcwCAg@mail.gmail.com>
Message-ID: <2f37acb9-018f-4edd-89c1-4d86bf64b92e@oracle.com>

Hi Stephane,

I think your tool is quite useful and I like the format (cut-and-pasted 
below) that it reports the statistics. It can be used to diagnose 
configuration problems so that the application can use CDS effectively.

I also use the -Xlog:class+load output a lot, but I usually just use 
ad-hoc scripts.

For Leyden, I think we should think about improved logging and 
diagnostics for other artifacts as well (heap objects, AOT methods, 
etc). Some sort of central place (like JFR) for accessing such 
information would be useful. Do you have suggestions for how to 
integrate with JFR?

Thanks

- Ioi

|-------------------------------------------------------------------------- 
Class Loading Report: 15909 classes and JDK proxies loaded 13140 
(82,59%) from cache 2769 (17,41%) from classpath Categories: Lambdas 
1736 (10,91%): 11,23% from cache Proxies 175 ( 1,10%): 56,57% from cache 
Classes 14000 (88,00%): 91,76% from cache Top 10 locations from 
classpath: 759 BOOT-INF/lib/byte-buddy-1.14.9.jar 347 
__JVM_LookupDefineClass__ 75 __dynamic_proxy__ 69 
org.springframework.boot.autoconfigure.web.embedded.TomcatWebServerFactoryCustomizer 
39 31 
org.springframework.boot.autoconfigure.web.servlet.ServletWebServerFactoryCustomizer 
19 org.springframework.data.mapping.model.Property 16 
org.springframework.core.io.support.SpringFactoriesLoader 16 
org.springframework.data.mapping.model.AnnotationBasedPersistentProperty 
16 org.springframework.boot.autoconfigure.web.WebProperties Top 10 
packages: 5078 org.springframework (77,37% from cache) 3776 
org.hibernate (92,77% from cache) 847 java.lang (60,45% from cache) 810 
net.bytebuddy (4,94% from cache) 737 java.util (98,78% from cache) 575 
org.h2 (98,09% from cache) 523 com.fasterxml (95,98% from cache) 323 
org.aspectj (100,00% from cache) 322 jdk.internal (99,07% from cache) 
310 org.apache (97,74% from cache) 
--------------------------------------------------------------------------|


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

From jianglizhou at google.com  Wed Jan 31 01:41:44 2024
From: jianglizhou at google.com (Jiangli Zhou)
Date: Tue, 30 Jan 2024 17:41:44 -0800
Subject: The 'modules' image (jimage) packaged JDK resources
Message-ID: <CALrW1jwSvmMFGp_2_SxJkhMyunp8cz6MrAkHU4wt0CNK0k46-g@mail.gmail.com>

As part of the discussions of bringing
https://github.com/openjdk/leyden/tree/hermetic-java-runtime related work
into OpenJDK mainline under the leyden project, some of us (cc'ed on the
email) have started brainstorming (in several zoom meetings) the idea of
placing JDK resources in the modules image (jimage). The resources would
include conf/*, lib/<resources>, etc in a regular JDK binary. In the
hermetic-java-runtime prototype, the JDK resources are packaged into an
executable JAR image as normal JAR entries. At runtime, accessing these
resources goes through a JavaHome
<https://github.com/openjdk/leyden/blob/hermetic-java-runtime/src/java.base/share/classes/jdk/internal/misc/JavaHome.java>
class
using a ZipFileSystem. If JDK resources are part of the modules, the
static/hermetic image packaging and runtime accessing becomes further
cleaner.

I recently prototyped that idea with a jlink plugin and some quick runtime
changes to access using Module.getResourceAsStream
<https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Module.html#getResourceAsStream(java.lang.String)>
(not
in the hermetic-java-runtime branch yet). The quick prototype indicates it
is feasible from an implementation point of view.  Following are a few
points that have been discussed among us for more broad discussions:

- This probably will involve specification changes in order to place the
JDK resources into the modules image. Particularly, the conf/* resource
files were intended to be user configurable (pointed out by Alan). Alan has
been looking into those parts.

- Where should the resources be placed within the modules image? For
example, if conf/security/java.security is written (using the new jlink
plugin) into the image as /java.base/java.security, runtime can just access
"java.security" resource using the "java.base" module (via
getResourceAsStream()). Alternatively, if the file is written as
/java.base/conf/security/java.security, the conf/security package needs to
be added for the java.base module.

Thoughts and input?

Thanks!
Jiangli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240130/f27df742/attachment.htm>

From Alan.Bateman at oracle.com  Wed Jan 31 11:01:06 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 Jan 2024 11:01:06 +0000
Subject: The 'modules' image (jimage) packaged JDK resources
In-Reply-To: <CALrW1jwSvmMFGp_2_SxJkhMyunp8cz6MrAkHU4wt0CNK0k46-g@mail.gmail.com>
References: <CALrW1jwSvmMFGp_2_SxJkhMyunp8cz6MrAkHU4wt0CNK0k46-g@mail.gmail.com>
Message-ID: <2f2a4463-4bec-4de9-a54c-3926df9e0696@oracle.com>

On 31/01/2024 01:41, Jiangli Zhou wrote:
> As part of the discussions of bringing 
> https://github.com/openjdk/leyden/tree/hermetic-java-runtime 
> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/tree/hermetic-java-runtime__;!!ACWV5N9M2RV99hQ!P1kaSBJTsyP-QDfpIa0aSJZkqSkjwowiqRo3Vvj3PVuVLfZAWE7wL8wChhhSWM7nzXUDk1x_p8jC0Yv6gqFZcQ8$> 
> related work into OpenJDK mainline under the leyden project, some of 
> us (cc'ed on the email) have started brainstorming (in several zoom 
> meetings) the idea of placing JDK resources in the modules?image 
> (jimage). The resources would include?conf/*, lib/<resources>, etc in 
> a regular JDK binary. In the hermetic-java-runtime prototype, the JDK 
> resources are packaged into an executable JAR image as normal JAR 
> entries. At runtime, accessing these resources goes through a JavaHome 
> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/hermetic-java-runtime/src/java.base/share/classes/jdk/internal/misc/JavaHome.java__;!!ACWV5N9M2RV99hQ!P1kaSBJTsyP-QDfpIa0aSJZkqSkjwowiqRo3Vvj3PVuVLfZAWE7wL8wChhhSWM7nzXUDk1x_p8jC0Yv6KzOBrxA$>?class 
> using a ZipFileSystem. If JDK resources are part of the modules, the 
> static/hermetic image packaging and runtime accessing becomes further 
> cleaner.
>
> I recently prototyped that idea with a jlink plugin and some quick 
> runtime changes to access using Module.getResourceAsStream 
> <https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Module.html#getResourceAsStream(java.lang.String)>?(not 
> in the hermetic-java-runtime branch yet). The quick prototype 
> indicates it is feasible from an implementation point of view.

You can also try Class.getResourceAsStream as it will locate the "data" 
relative to the class that owns it. You'll find several examples in the 
JDK that do this already, e.g. legacy sun.net.www.MimeTable uses it to 
locate a properties file with default mappings.


> Following are a few points that have been discussed among us for more 
> broad discussions:
>
> - This probably will involve specification changes in order to place 
> the JDK resources into the modulesimage. Particularly, the 
> conf/*resource files were?intended to be user configurable (pointed 
> out by Alan). Alan has been looking into those parts.

There are a dozen or so APIs that specify support for user-editable 
configuration in the run-time image. Some of these APIs already specify 
ways to override or augment with configuration that comes from somewhere 
else, some APIs do not. So some adjustments will be required to all of 
these APIs and it's an opportunity to get bring some consistency across 
the JDK at the same time.

The other bucket is data/other files in the lib tree. These won't 
require specification changes but they do have some implications, e.g. 
TZ data, replacing cacerts with a sym link, and a few others that have 
to be worked through.


>
> - Where should the resources be placed within the modulesimage? For 
> example, if conf/security/java.security?is written (using the new 
> jlink plugin) into the image as /java.base/java.security, runtime can 
> just access "java.security" resource using the "java.base" module (via 
> getResourceAsStream()). Alternatively, if the file is written as 
> /java.base/conf/security/java.security, the conf/securitypackage needs 
> to be added for the java.basemodule.
>
For the user-editable configuration then the answer will be "nowhere" in 
most cases. The reason is that user editable in the run-time image is 
optional, as is the value for specific keys, so there are already 
defaults. So it might be that when jlink creates a static image that it 
just drops the resources in the "conf" section of each module.? 
java.security will need special attention of course, it's a bit of an 
outlier right now.

The non-editable configuration needs thinking through as there are a 
number of options. As you point out, if the file is moved to be a 
resource in a "new package" then the module's set of packages will need 
to be expanded at packaging or link time. It's usually nice when the 
structure of the "output tree" matches the original "input tree" so if 
they are in the lib tree in the packaged module, the lib tree in the 
modular run-time image, then having them move to be resources in the 
"internal" lib tree in the static image might be the least surprising.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240131/5c25d1ac/attachment.htm>

From jianglizhou at google.com  Wed Jan 31 18:35:34 2024
From: jianglizhou at google.com (Jiangli Zhou)
Date: Wed, 31 Jan 2024 10:35:34 -0800
Subject: The 'modules' image (jimage) packaged JDK resources
In-Reply-To: <2f2a4463-4bec-4de9-a54c-3926df9e0696@oracle.com>
References: <CALrW1jwSvmMFGp_2_SxJkhMyunp8cz6MrAkHU4wt0CNK0k46-g@mail.gmail.com>
 <2f2a4463-4bec-4de9-a54c-3926df9e0696@oracle.com>
Message-ID: <CALrW1jywP8CL7kEqziP1wY4p-iQM8Cbn94vdLpb9ViTW4c1+sA@mail.gmail.com>

Thanks, Alan! This clarifies things quite a bit.

On Wed, Jan 31, 2024 at 3:01?AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:
>
> On 31/01/2024 01:41, Jiangli Zhou wrote:
>
> As part of the discussions of bringing
https://github.com/openjdk/leyden/tree/hermetic-java-runtime related work
into OpenJDK mainline under the leyden project, some of us (cc'ed on the
email) have started brainstorming (in several zoom meetings) the idea of
placing JDK resources in the modules image (jimage). The resources would
include conf/*, lib/<resources>, etc in a regular JDK binary. In the
hermetic-java-runtime prototype, the JDK resources are packaged into an
executable JAR image as normal JAR entries. At runtime, accessing these
resources goes through a JavaHome class using a ZipFileSystem. If JDK
resources are part of the modules, the static/hermetic image packaging and
runtime accessing becomes further cleaner.
>
> I recently prototyped that idea with a jlink plugin and some quick
runtime changes to access using Module.getResourceAsStream (not in the
hermetic-java-runtime branch yet). The quick prototype indicates it is
feasible from an implementation point of view.
>
>
> You can also try Class.getResourceAsStream as it will locate the "data"
relative to the class that owns it. You'll find several examples in the JDK
that do this already, e.g. legacy sun.net.www.MimeTable uses it to locate a
properties file with default mappings.
>

Thanks for the example. Looking closely at Class.getResourceAsStream
<https://github.com/openjdk/jdk/blob/2cd1ba6a52eafffa65d0f2532a07fff89f9cea0e/src/java.base/share/classes/java/lang/Class.java#L3063>,
I see it resolves the full resource name by prepending the package name of
the current class if necessary. So it looks like co-locating (in the modules
image) the resources from lib/ with the classes that accessing the
resources as you suggested is the cleanest.  As an example,
lib/security/blocked.certs (used by sun.security.util.UntrustedCertificates)
can be located as /java.base/sun/security/util/blocked.certs within the
modules file.

One other related thought/question, any potential issues if we place the
lib/ resources in modules by default for regular JDK, instead of just for
static images?

>
> Following are a few points that have been discussed among us for more
broad discussions:
>
> - This probably will involve specification changes in order to place the
JDK resources into the modules image. Particularly, the conf/* resource
files were intended to be user configurable (pointed out by Alan). Alan has
been looking into those parts.
>
>
> There are a dozen or so APIs that specify support for user-editable
configuration in the run-time image. Some of these APIs already specify
ways to override or augment with configuration that comes from somewhere
else, some APIs do not. So some adjustments will be required to all of
these APIs and it's an opportunity to get bring some consistency across the
JDK at the same time.
>
> The other bucket is data/other files in the lib tree. These won't require
specification changes but they do have some implications, e.g. TZ data,
replacing cacerts with a sym link, and a few others that have to be worked
through.
>
>
>
> - Where should the resources be placed within the modules image? For
example, if conf/security/java.security is written (using the new jlink
plugin) into the image as /java.base/java.security, runtime can just access
"java.security" resource using the "java.base" module (via
getResourceAsStream()). Alternatively, if the file is written as
/java.base/conf/security/java.security, the conf/security package needs to
be added for the java.base module.
>
> For the user-editable configuration then the answer will be "nowhere" in
most cases. The reason is that user editable in the run-time image is
optional, as is the value for specific keys, so there are already defaults.
So it might be that when jlink creates a static image that it just drops
the resources in the "conf" section of each module.  java.security will
need special attention of course, it's a bit of an outlier right now.
>

Yeah, java.security can be overridden by java.security.properties specified
security property file if security.overridePropertiesFile is true. In that
sense, users should provide their own property file instead of modifying
the master security property file. It seems we may want to put
java.security in the modules as /java.base/java/lang/security/java.security?

Thanks!
Jiangli

> The non-editable configuration needs thinking through as there are a
number of options. As you point out, if the file is moved to be a resource
in a "new package" then the module's set of packages will need to be
expanded at packaging or link time. It's usually nice when the structure of
the "output tree" matches the original "input tree" so if they are in the
lib tree in the packaged module, the lib tree in the modular run-time
image, then having them move to be resources in the "internal" lib tree in
the static image might be the least surprising.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240131/16fe4b92/attachment.htm>