From duke at openjdk.org  Thu Aug  1 02:55:22 2024
From: duke at openjdk.org (duke)
Date: Thu, 1 Aug 2024 02:55:22 GMT
Subject: git: openjdk/leyden: premain: 2 new changesets
Message-ID: <694fe217-eaab-4edf-9375-b40195fba8c1@openjdk.org>

Changeset: 1e18a09d
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-31 14:19:41 +0000
URL:       https://git.openjdk.org/leyden/commit/1e18a09d2e82b801c9d1e2e340fd8ca991103fae

Refactoring of ClassPreloader and ClassPrelinker. Now we have AOTClassLinker, AOTConstantPoolResolver and AOTLinkedClassBulkLoader

+ src/hotspot/share/cds/aotClassLinker.cpp
+ src/hotspot/share/cds/aotClassLinker.hpp
+ src/hotspot/share/cds/aotConstantPoolResolver.cpp
= src/hotspot/share/cds/aotConstantPoolResolver.hpp
+ src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp
+ src/hotspot/share/cds/aotLinkedClassBulkLoader.hpp
+ src/hotspot/share/cds/aotLinkedClassTable.cpp
+ src/hotspot/share/cds/aotLinkedClassTable.hpp
! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/archiveUtils.cpp
! src/hotspot/share/cds/cdsConfig.cpp
! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/cds/classListWriter.cpp
- src/hotspot/share/cds/classPrelinker.cpp
- src/hotspot/share/cds/classPreloader.cpp
- src/hotspot/share/cds/classPreloader.hpp
! src/hotspot/share/cds/dumpAllocStats.cpp
! src/hotspot/share/cds/dynamicArchive.cpp
! src/hotspot/share/cds/finalImageRecipes.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/classfile/vmClasses.cpp
! src/hotspot/share/compiler/compilationPolicy.cpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/interpreter/interpreterRuntime.hpp
! src/hotspot/share/oops/constantPool.cpp
! src/hotspot/share/oops/constantPool.hpp
! src/hotspot/share/oops/cpCache.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/runtime/threads.cpp
+ test/hotspot/jtreg/runtime/cds/appcds/preloadedClasses/EarlyClassLoading.java
! test/lib/jdk/test/lib/cds/CDSAppTester.java

Changeset: ee11cf1b
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-29 22:15:33 +0000
URL:       https://git.openjdk.org/leyden/commit/ee11cf1b9420d60be6febdc531f689f9c9e8091c

Exclude test cases that cannot be executed with -Dtest.dynamic.cds.archive=true

! test/hotspot/jtreg/TEST.groups
! test/lib/jdk/test/lib/cds/CDSAppTester.java


From duke at openjdk.org  Fri Aug  2 21:38:50 2024
From: duke at openjdk.org (duke)
Date: Fri, 2 Aug 2024 21:38:50 GMT
Subject: git: openjdk/leyden: premain: 3 new changesets
Message-ID: <04247f0a-e6a1-4c48-b548-5a1446ee6db8@openjdk.org>

Changeset: 12225130
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-02 09:39:29 +0000
URL:       https://git.openjdk.org/leyden/commit/122251307e2627e2261c08fbb109dad57e98227e

Added -XX:AOTMode=on/off/auto

! src/hotspot/share/cds/cdsConfig.cpp
! src/hotspot/share/cds/cds_globals.hpp
! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/runtime/flags/jvmFlagAccess.cpp
! src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.cpp
! src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.hpp
! test/hotspot/jtreg/runtime/cds/appcds/AOTFlags.java

Changeset: dce3658c
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-02 10:17:48 +0000
URL:       https://git.openjdk.org/leyden/commit/dce3658cd5ad60356d5cd0b3afb4caae46e27de3

Cleanup: added CDSConfig::is_using_aot_linked_classes()

! src/hotspot/share/cds/aotClassLinker.cpp
! src/hotspot/share/cds/aotConstantPoolResolver.cpp
! src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp
! src/hotspot/share/cds/aotLinkedClassTable.cpp
! src/hotspot/share/cds/archiveUtils.cpp
! src/hotspot/share/cds/cdsConfig.cpp
! src/hotspot/share/cds/cdsConfig.hpp
! src/hotspot/share/cds/dumpTimeClassInfo.cpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp

Changeset: 9a4ea6ff
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-02 14:36:51 +0000
URL:       https://git.openjdk.org/leyden/commit/9a4ea6ffbdbb9600b9c36e821bfc7522e19a01b2

preload classes tests do not work with ZGC

! test/hotspot/jtreg/TEST.ROOT
! test/hotspot/jtreg/runtime/cds/appcds/preloadedClasses/EarlyClassLoading.java
! test/hotspot/jtreg/runtime/cds/appcds/preloadedClasses/PreloadedClassesVerification.java
! test/jtreg-ext/requires/VMProps.java


From duke at openjdk.org  Fri Aug  2 23:51:05 2024
From: duke at openjdk.org (duke)
Date: Fri, 2 Aug 2024 23:51:05 GMT
Subject: git: openjdk/leyden: premain: Do not use decomp count for one step
 workflow
Message-ID: <e6ac45c3-e60b-4518-8912-097348a20dc3@openjdk.org>

Changeset: d9811b4a
Branch: premain
Author:    Vladimir Kozlov <vladimir.kozlov at oracle.com>
Committer: iklam <ilam3388 at gmail.com>
Date:      2024-07-26 15:12:42 +0000
URL:       https://git.openjdk.org/leyden/commit/d9811b4a6cef8fd4c9d1adeec5da54825a1ff786

Do not use decomp count for one step workflow

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


From mark.reinhold at oracle.com  Sun Aug  4 21:46:46 2024
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Sun, 4 Aug 2024 21:46:46 +0000
Subject: New candidate JEP: 483: Ahead-of-Time Class Loading & Linking
Message-ID: <20240804214645.C91D474545A@eggemoggin.niobe.net>

https://openjdk.org/jeps/483

  Summary: Improve startup time by making the classes of an application
  instantly available, in a loaded and linked state, when the
  HotSpot Java Virtual Machine starts.  Achieve this by monitoring the
  application during one run and storing the loaded and linked forms of
  all classes in a cache for use in subsequent runs.  Lay a foundation
  for future improvements to both startup and warmup time.

- Mark

From duke at openjdk.org  Tue Aug  6 03:37:07 2024
From: duke at openjdk.org (duke)
Date: Tue, 6 Aug 2024 03:37:07 GMT
Subject: git: openjdk/leyden: premain: 2 new changesets
Message-ID: <b2958b08-ae5b-43da-ba43-31cd7be2109b@openjdk.org>

Changeset: c01a9bce
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-03 08:58:16 +0000
URL:       https://git.openjdk.org/leyden/commit/c01a9bce2143ba4d0cde182b7f5b2f0cb87b0265

fixed windows build

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

Changeset: 8b148497
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-03 21:55:45 +0000
URL:       https://git.openjdk.org/leyden/commit/8b148497559f9633ca159e555109340cbdbe6e20

renamed -XX:+PreloadSharedClasses to -XX:+AOTClassLinking

! README.md
! src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp
! src/hotspot/share/cds/cdsConfig.cpp
! src/hotspot/share/cds/cds_globals.hpp
! src/hotspot/share/cds/heapShared.cpp
! test/hotspot/jtreg/TEST.groups
! test/hotspot/jtreg/premain/javac/javac-test.sh
! test/hotspot/jtreg/premain/lib/DemoSupport.gmk
! test/hotspot/jtreg/premain/spring-petclinic/Makefile
! test/hotspot/jtreg/premain/spring-petclinic/WarmupMakefile
+ test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/AOTClassLinkingVMOptions.java
= test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/AOTClassLinkingVerification.java
= test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/BadNewClass.jasm
= test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/BadNewClass2.jasm
= test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/BadOldClass.jasm
= test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/BadOldClass2.jasm
+ test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java
= test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/GoodOldClass.jasm
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedPackages.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedProtectionDomains.java
! test/hotspot/jtreg/runtime/cds/appcds/indy/IndyTestBase.java
! test/hotspot/jtreg/runtime/cds/appcds/indy/StringConcatStress2.java
! test/hotspot/jtreg/runtime/cds/appcds/jvmti/ClassFileLoadHookTest.java
! test/hotspot/jtreg/runtime/cds/appcds/leyden/LeydenAndOldClasses.java
- test/hotspot/jtreg/runtime/cds/appcds/preloadedClasses/EarlyClassLoading.java
- test/hotspot/jtreg/runtime/cds/appcds/preloadedClasses/PreloadedClassesVMOptions.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbCDSCore.java
! test/lib/jdk/test/lib/cds/CDSAppTester.java


From asmehra at redhat.com  Tue Aug  6 13:38:34 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Tue, 6 Aug 2024 09:38:34 -0400
Subject: git: openjdk/leyden: premain: Do not use decomp count for one
 step workflow
In-Reply-To: <e6ac45c3-e60b-4518-8912-097348a20dc3@openjdk.org>
References: <e6ac45c3-e60b-4518-8912-097348a20dc3@openjdk.org>
Message-ID: <CAKt0pyTA_dNhZHFH7gGgMZKdJ-c-FzAOVH403ido7a4mXd31Gw@mail.gmail.com>

I think this change is not specific to one-step workflow; it applies to
5-step workflow as well, right?

- Ashutosh Mehra


On Fri, Aug 2, 2024 at 7:51?PM duke <duke at openjdk.org> wrote:

> Changeset: d9811b4a
> Branch: premain
> Author:    Vladimir Kozlov <vladimir.kozlov at oracle.com>
> Committer: iklam <ilam3388 at gmail.com>
> Date:      2024-07-26 15:12:42 +0000
> URL:
> https://git.openjdk.org/leyden/commit/d9811b4a6cef8fd4c9d1adeec5da54825a1ff786
>
> Do not use decomp count for one step workflow
>
> ! src/hotspot/share/code/SCCache.cpp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240806/52ac31e4/attachment.htm>

From vladimir.kozlov at oracle.com  Tue Aug  6 17:12:12 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 6 Aug 2024 10:12:12 -0700
Subject: [External] : Re: git: openjdk/leyden: premain: Do not use decomp
 count for one step workflow
In-Reply-To: <CAKt0pyTA_dNhZHFH7gGgMZKdJ-c-FzAOVH403ido7a4mXd31Gw@mail.gmail.com>
References: <e6ac45c3-e60b-4518-8912-097348a20dc3@openjdk.org>
 <CAKt0pyTA_dNhZHFH7gGgMZKdJ-c-FzAOVH403ido7a4mXd31Gw@mail.gmail.com>
Message-ID: <dcd240b6-4c07-43ef-9859-84ac5e124138@oracle.com>

You are right, Ashutosh.

It was point fix for Leyden EA where we advertise use one-step workflow 
only.

In premain we need more complicated changes to address this issue to 
cover both workflows. At least we need to check in which mode we are. I 
did not have time to look into it yet.

If you know how to fix it then do it.

Thanks,
Vladimir K

On 8/6/24 6:38 AM, Ashutosh Mehra wrote:
> I think this change is not specific to one-step workflow; it applies to 
> 5-step workflow as well, right?
> 
> - Ashutosh Mehra
> 
> 
> On Fri, Aug 2, 2024 at 7:51?PM duke <duke at openjdk.org 
> <mailto:duke at openjdk.org>> wrote:
> 
>     Changeset: d9811b4a
>     Branch: premain
>     Author:? ? Vladimir Kozlov <vladimir.kozlov at oracle.com
>     <mailto:vladimir.kozlov at oracle.com>>
>     Committer: iklam <ilam3388 at gmail.com <mailto:ilam3388 at gmail.com>>
>     Date:? ? ? 2024-07-26 15:12:42 +0000
>     URL:
>     https://git.openjdk.org/leyden/commit/d9811b4a6cef8fd4c9d1adeec5da54825a1ff786 <https://git.openjdk.org/leyden/commit/d9811b4a6cef8fd4c9d1adeec5da54825a1ff786>
> 
>     Do not use decomp count for one step workflow
> 
>     ! src/hotspot/share/code/SCCache.cpp
> 

From duke at openjdk.org  Wed Aug  7 04:22:17 2024
From: duke at openjdk.org (duke)
Date: Wed, 7 Aug 2024 04:22:17 GMT
Subject: git: openjdk/leyden: premain: 8337965: Add null check to
 ClaimMetadataVisitingOopIterateClosure::do_cld()
Message-ID: <5b5eff34-1fdf-48e6-b0d1-b5c10e8ad4e0@openjdk.org>

Changeset: 0d054eb4
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-06 20:28:34 +0000
URL:       https://git.openjdk.org/leyden/commit/0d054eb4e10081dbda1c803f8481ba2de172f2c6

8337965: Add null check to ClaimMetadataVisitingOopIterateClosure::do_cld()

! src/hotspot/share/memory/iterator.inline.hpp
! test/hotspot/jtreg/runtime/cds/appcds/indy/IndyTestBase.java
! test/lib/jdk/test/lib/cds/CDSAppTester.java


From duke at openjdk.org  Thu Aug  8 05:58:57 2024
From: duke at openjdk.org (duke)
Date: Thu, 8 Aug 2024 05:58:57 GMT
Subject: git: openjdk/leyden: premain: 2 new changesets
Message-ID: <2cbbe427-ba21-4d03-89e1-58c3314b6fc5@openjdk.org>

Changeset: 0bcbbff9
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-07 19:46:36 +0000
URL:       https://git.openjdk.org/leyden/commit/0bcbbff95fe0ed4676a3b7985906a2b1a20b3c18

more clean up on new AOTxxx command-line flags

! src/hotspot/share/cds/cdsConfig.cpp
! src/hotspot/share/cds/cds_globals.hpp
! test/hotspot/jtreg/runtime/cds/appcds/AOTFlags.java

Changeset: 82c7ad0d
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-07 22:57:52 +0000
URL:       https://git.openjdk.org/leyden/commit/82c7ad0d94951b8ffb61bf0b0864fe0ca3e735df

8338011: CDS archived heap object support for 64-bit Windows

! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/utilities/macros.hpp


From dannyt at netflix.com  Fri Aug  9 20:38:12 2024
From: dannyt at netflix.com (Danny Thomas)
Date: Fri, 9 Aug 2024 13:38:12 -0700
Subject: EA feedback
Message-ID: <CAABjz10oAmoLkEfLSLo0MN7+BzCFQJ5VYSkmhWH6GB6SVrF57Q@mail.gmail.com>

I tried 24-leydenpremain+2-8 on a few internal applications, some quick
feedback below (good to see you folks at the JVM LS!).

If a jar has a Class-Path attribute and one or more of those libraries are
explicitly on the classpath, it causes the actual and expected classpath to
always differ. This is also the case currently with CDS of course, but this
feature is sure to be deployed far more broadly than CDS is currently, so
likely something you want to look at:

[0.057s][info][class,path] non-existent Class-Path entry
lib/failureaccess-1.0.1.jar
[0.057s][info][class,path] opened:
lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
[0.057s][info][class,path] library =
lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar

Startup time when training seems to be on par with ArchiveClassesAtExit in
JDK 21, but it's about a 3.5x startup time penalty for one of our typical
Spring Boot applications. From a back-to-back run on my machine (AMD EPYC
9R14, 32 cores, 123G, Ubuntu 22.04.4 LTS):

Started App in 7.698 seconds (process running for 8.229)
Started App in 26.247 seconds (process running for 29.262) - w/
CacheDataStore, Training Run
Started App in 4.341 seconds (process running for 4.917)  - w/
CacheDataStore, Production Run

I also got a crash on one attempt, I can't remember what I did to cause
this unfortunately:

Stack: [0x00007f3949ab0000,0x00007f3949bb0000],  sp=0x00007f3949bae628,
 free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)
V  [libjvm.so+0x42ca30]  ArchiveBuilder::get_buffered_addr(unsigned char*)
const+0x40
V  [libjvm.so+0xce4aa5]  VM_PopulateDumpSharedSpace::doit()+0x395
V  [libjvm.so+0x100ae69]  VM_Operation::evaluate()+0x109
V  [libjvm.so+0x100e348]  VMThread::evaluate_operation(VM_Operation*)+0xe8
V  [libjvm.so+0x10142fb]  VMThread::inner_execute(VM_Operation*)+0x35b
V  [libjvm.so+0x101460f]  VMThread::run()+0x16f
V  [libjvm.so+0xf6e5cf]  Thread::call_run()+0x9f
V  [libjvm.so+0xd74e13]  thread_native_entry(Thread*)+0x183
C  [libc.so.6+0x98b07]

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
0x0000000000000030

Thinking ahead to operationalizing AOT, while a single-shot/on-exit
workflow is great for iterating locally, requiring the VM to exit makes
this more difficult to operationalize at scale:

   1. We'll perform training and assembly on test, production canary and
   production instances on behalf of application owners and handle
   distribution of the archives. Depending on when we're able to perform a
   training run, it'll have different benefits. i.e.:
      1. Test environment will at least improve startup performance, with a
      mixed benefit for warm up depending on the kind of traffic they
take in test
      2. If an application uses canary deployments we'll have a full
      production profile prior to the full production deployment, and all
      instances will come up hot
      3. If we reach production with only a test environment profile, we'll
      perform a training run in production, so instances that scale up
following
      that run will come up hot (completely cold instances for an initial
      deployment is less of a concern, because we deploy immutably and get a
      natural warm-up period while we have 200% capacity online for a cluster)
   2. It's currently not a problem if a VM doesn't exit completely due to a
   dangling non-daemon thread or hung shutdown hook

Being able to trigger assembly/verification via jcmd without exiting, would
make this far easier for us to support. If the overhead of the
instrumentation for CDS can be avoided, being able to take a snapshot at
any time on any VM would be better still, but that wouldn't be an
impediment for us: we'll know that the instance will be used for training
at boot time.

We build nightlies of all the currently active OpenJDK projects, so if you
land anything on premain between EA builds that you'd like us to try, let
us know!

Cheers,
Danny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240809/f892a79b/attachment.htm>

From duke at openjdk.org  Fri Aug  9 22:12:52 2024
From: duke at openjdk.org (duke)
Date: Fri, 9 Aug 2024 22:12:52 GMT
Subject: git: openjdk/leyden: premain: Ignore decomp counter for one-step.
 Cleanup in prints.
Message-ID: <50a4c39d-9dca-4a64-851c-7e72565eb889@openjdk.org>

Changeset: 9f24a918
Branch: premain
Author:    Vladimir Kozlov <vladimir.kozlov at oracle.com>
Date:      2024-08-09 15:11:52 +0000
URL:       https://git.openjdk.org/leyden/commit/9f24a9187df972db2b363273014855599390cc5e

Ignore decomp counter for one-step. Cleanup in prints.

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


From vladimir.kozlov at oracle.com  Sat Aug 10 02:03:17 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 9 Aug 2024 19:03:17 -0700
Subject: [External] : Re: git: openjdk/leyden: premain: Do not use decomp
 count for one step workflow
In-Reply-To: <dcd240b6-4c07-43ef-9859-84ac5e124138@oracle.com>
References: <e6ac45c3-e60b-4518-8912-097348a20dc3@openjdk.org>
 <CAKt0pyTA_dNhZHFH7gGgMZKdJ-c-FzAOVH403ido7a4mXd31Gw@mail.gmail.com>
 <dcd240b6-4c07-43ef-9859-84ac5e124138@oracle.com>
Message-ID: <ca8c2ec3-17e4-434c-92e0-f5c3ab1949f9@oracle.com>

Hi Ashutosh,

I pushed today fix into `premain` branch to handle both workflow.

Vladimir K

On 8/6/24 10:12 AM, Vladimir Kozlov wrote:
> You are right, Ashutosh.
> 
> It was point fix for Leyden EA where we advertise use one-step workflow 
> only.
> 
> In premain we need more complicated changes to address this issue to 
> cover both workflows. At least we need to check in which mode we are. I 
> did not have time to look into it yet.
> 
> If you know how to fix it then do it.
> 
> Thanks,
> Vladimir K
> 
> On 8/6/24 6:38 AM, Ashutosh Mehra wrote:
>> I think this change is not specific to one-step workflow; it applies 
>> to 5-step workflow as well, right?
>>
>> - Ashutosh Mehra
>>
>>
>> On Fri, Aug 2, 2024 at 7:51?PM duke <duke at openjdk.org 
>> <mailto:duke at openjdk.org>> wrote:
>>
>> ??? Changeset: d9811b4a
>> ??? Branch: premain
>> ??? Author:? ? Vladimir Kozlov <vladimir.kozlov at oracle.com
>> ??? <mailto:vladimir.kozlov at oracle.com>>
>> ??? Committer: iklam <ilam3388 at gmail.com <mailto:ilam3388 at gmail.com>>
>> ??? Date:? ? ? 2024-07-26 15:12:42 +0000
>> ??? URL:
>>     
>> https://git.openjdk.org/leyden/commit/d9811b4a6cef8fd4c9d1adeec5da54825a1ff786 <https://git.openjdk.org/leyden/commit/d9811b4a6cef8fd4c9d1adeec5da54825a1ff786>
>>
>> ??? Do not use decomp count for one step workflow
>>
>> ??? ! src/hotspot/share/code/SCCache.cpp
>>

From asmehra at redhat.com  Mon Aug 12 14:13:54 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Mon, 12 Aug 2024 10:13:54 -0400
Subject: [External] : Re: git: openjdk/leyden: premain: Do not use decomp
 count for one step workflow
In-Reply-To: <ca8c2ec3-17e4-434c-92e0-f5c3ab1949f9@oracle.com>
References: <e6ac45c3-e60b-4518-8912-097348a20dc3@openjdk.org>
 <CAKt0pyTA_dNhZHFH7gGgMZKdJ-c-FzAOVH403ido7a4mXd31Gw@mail.gmail.com>
 <dcd240b6-4c07-43ef-9859-84ac5e124138@oracle.com>
 <ca8c2ec3-17e4-434c-92e0-f5c3ab1949f9@oracle.com>
Message-ID: <CAKt0pyQ2khmftyV+bimrdvaqsGxoZW3XDe7h1kGtdWSDcmj0fw@mail.gmail.com>

Looks good. Thanks for addressing it.

Regards,
- Ashutosh Mehra


On Fri, Aug 9, 2024 at 10:03?PM Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

> Hi Ashutosh,
>
> I pushed today fix into `premain` branch to handle both workflow.
>
> Vladimir K
>
> On 8/6/24 10:12 AM, Vladimir Kozlov wrote:
> > You are right, Ashutosh.
> >
> > It was point fix for Leyden EA where we advertise use one-step workflow
> > only.
> >
> > In premain we need more complicated changes to address this issue to
> > cover both workflows. At least we need to check in which mode we are. I
> > did not have time to look into it yet.
> >
> > If you know how to fix it then do it.
> >
> > Thanks,
> > Vladimir K
> >
> > On 8/6/24 6:38 AM, Ashutosh Mehra wrote:
> >> I think this change is not specific to one-step workflow; it applies
> >> to 5-step workflow as well, right?
> >>
> >> - Ashutosh Mehra
> >>
> >>
> >> On Fri, Aug 2, 2024 at 7:51?PM duke <duke at openjdk.org
> >> <mailto:duke at openjdk.org>> wrote:
> >>
> >>     Changeset: d9811b4a
> >>     Branch: premain
> >>     Author:    Vladimir Kozlov <vladimir.kozlov at oracle.com
> >>     <mailto:vladimir.kozlov at oracle.com>>
> >>     Committer: iklam <ilam3388 at gmail.com <mailto:ilam3388 at gmail.com>>
> >>     Date:      2024-07-26 15:12:42 +0000
> >>     URL:
> >>
> >>
> https://git.openjdk.org/leyden/commit/d9811b4a6cef8fd4c9d1adeec5da54825a1ff786
> <
> https://git.openjdk.org/leyden/commit/d9811b4a6cef8fd4c9d1adeec5da54825a1ff786
> >
> >>
> >>     Do not use decomp count for one step workflow
> >>
> >>     ! src/hotspot/share/code/SCCache.cpp
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240812/2078126f/attachment.htm>

From calvin.cheung at oracle.com  Tue Aug 13 03:54:10 2024
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Mon, 12 Aug 2024 20:54:10 -0700
Subject: EA feedback
In-Reply-To: <CAABjz10oAmoLkEfLSLo0MN7+BzCFQJ5VYSkmhWH6GB6SVrF57Q@mail.gmail.com>
References: <CAABjz10oAmoLkEfLSLo0MN7+BzCFQJ5VYSkmhWH6GB6SVrF57Q@mail.gmail.com>
Message-ID: <91d5033c-7c0d-4670-8b38-b801dd2ceea1@oracle.com>

Hi Danny,

On 8/9/24 1:38 PM, Danny Thomas wrote:
> I tried?24-leydenpremain+2-8 on a few internal applications, some 
> quick feedback below (good to see you folks at the JVM LS!).
Thanks for trying the EA build.
>
> If a jar has a Class-Path attribute and?one or more of those libraries 
> are explicitly on the classpath, it causes the actual and expected 
> classpath to always differ. This is also the case currently with CDS 
> of course, but this feature is sure to be deployed far more broadly 
> than CDS is currently, so likely something you want to look at:
>
> [0.057s][info][class,path] non-existent Class-Path entry 
> lib/failureaccess-1.0.1.jar
> [0.057s][info][class,path] opened: 
> lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
> [0.057s][info][class,path] library = 
> lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar

I couldn't reproduce the above Class-Path attribute issue with a simple 
test[1]. The simple test was extracted from an existing test case[2].

Can you provide a test case?

(I'll let others to answer the other issues.)

Thanks,
Calvin
[1] https://cr.openjdk.org/~ccheung/cp-attribute/
[2] 
https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/cds/appcds/ClassPathAttr.java
>
> Startup time when training seems to be on par 
> with?ArchiveClassesAtExit in JDK 21, but it's?about a 3.5x startup 
> time penalty for one of our typical Spring Boot applications. From a 
> back-to-back run on my machine (AMD EPYC 9R14, 32 cores, 123G, Ubuntu 
> 22.04.4 LTS):
>
> Started App in 7.698 seconds (process running for 8.229)
> Started App in 26.247 seconds (process running for 29.262) - w/ 
> CacheDataStore, Training Run
> Started App in 4.341 seconds (process running for 4.917)??- w/ 
> CacheDataStore, Production Run
>
> I also got a crash on one attempt, I can't remember what I did to 
> cause this unfortunately:
>
> Stack: [0x00007f3949ab0000,0x00007f3949bb0000], 
> ?sp=0x00007f3949bae628, ?free space=1017k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
> C=native code)
> V ?[libjvm.so+0x42ca30] ?ArchiveBuilder::get_buffered_addr(unsigned 
> char*) const+0x40
> V ?[libjvm.so+0xce4aa5] ?VM_PopulateDumpSharedSpace::doit()+0x395
> V ?[libjvm.so+0x100ae69] ?VM_Operation::evaluate()+0x109
> V ?[libjvm.so+0x100e348] ?VMThread::evaluate_operation(VM_Operation*)+0xe8
> V ?[libjvm.so+0x10142fb] ?VMThread::inner_execute(VM_Operation*)+0x35b
> V ?[libjvm.so+0x101460f] ?VMThread::run()+0x16f
> V ?[libjvm.so+0xf6e5cf] ?Thread::call_run()+0x9f
> V ?[libjvm.so+0xd74e13] ?thread_native_entry(Thread*)+0x183
> C ?[libc.so.6+0x98b07]
>
> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 
> 0x0000000000000030
>
> Thinking ahead to operationalizing AOT, while a single-shot/on-exit 
> workflow is great for iterating locally, requiring the VM to exit 
> makes this more difficult to operationalize at scale:
>
>  1. We'll perform training and assembly on test, production canary and
>     production instances on behalf of application owners and handle
>     distribution of the archives. Depending on when we're able to
>     perform a training run, it'll have different benefits. i.e.:
>      1. Test environment will at least improve startup performance,
>         with a mixed benefit for warm up depending on the kind of
>         traffic they take in test
>      2. If an application uses canary deployments we'll have a full
>         production profile prior to the full production deployment,
>         and all instances will come up hot
>      3. If we reach production with only a test environment profile,
>         we'll perform a training run in production, so instances that
>         scale up following that run will come up hot (completely cold
>         instances for an initial deployment is less of a concern,
>         because we deploy immutably and get a natural warm-up period
>         while we have 200% capacity online for a cluster)
>  2. It's currently not a problem if a VM doesn't exit completely due
>     to a dangling non-daemon thread or hung shutdown hook
>
> Being able to trigger assembly/verification via jcmd without 
> exiting,?would make this far easier for?us to support. If the overhead 
> of the instrumentation for CDS can?be avoided, being able to take a 
> snapshot at any time on any VM would be better still, but that 
> wouldn't be an impediment for us:?we'll know that the instance will be 
> used for training at boot time.
>
> We build nightlies of all the currently active OpenJDK projects, so if 
> you land anything on premain between EA builds that you'd like us to 
> try, let us know!
>
> Cheers,
> Danny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240812/d52b1a57/attachment.htm>

From asmehra at redhat.com  Tue Aug 13 19:42:44 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Tue, 13 Aug 2024 15:42:44 -0400
Subject: EA feedback
In-Reply-To: <CAABjz10oAmoLkEfLSLo0MN7+BzCFQJ5VYSkmhWH6GB6SVrF57Q@mail.gmail.com>
References: <CAABjz10oAmoLkEfLSLo0MN7+BzCFQJ5VYSkmhWH6GB6SVrF57Q@mail.gmail.com>
Message-ID: <CAKt0pySHtZHSk0FyarM7kkdygTBppHBcYfpXPOfiJuS+7qjQyg@mail.gmail.com>

>
> Being able to trigger assembly/verification via jcmd without
> exiting, would make this far easier for us to support.
>

There is a proposed enhancement for doing exactly this (and exploring other
ways to trigger end of training run); see
https://bugs.openjdk.org/browse/JDK-8335358

Thanks,
- Ashutosh Mehra


On Fri, Aug 9, 2024 at 4:38?PM Danny Thomas <dannyt at netflix.com> wrote:

> I tried 24-leydenpremain+2-8 on a few internal applications, some quick
> feedback below (good to see you folks at the JVM LS!).
>
> If a jar has a Class-Path attribute and one or more of those libraries are
> explicitly on the classpath, it causes the actual and expected classpath to
> always differ. This is also the case currently with CDS of course, but this
> feature is sure to be deployed far more broadly than CDS is currently, so
> likely something you want to look at:
>
> [0.057s][info][class,path] non-existent Class-Path entry
> lib/failureaccess-1.0.1.jar
> [0.057s][info][class,path] opened:
> lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
> [0.057s][info][class,path] library =
> lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
>
> Startup time when training seems to be on par with ArchiveClassesAtExit in
> JDK 21, but it's about a 3.5x startup time penalty for one of our typical
> Spring Boot applications. From a back-to-back run on my machine (AMD EPYC
> 9R14, 32 cores, 123G, Ubuntu 22.04.4 LTS):
>
> Started App in 7.698 seconds (process running for 8.229)
> Started App in 26.247 seconds (process running for 29.262) - w/
> CacheDataStore, Training Run
> Started App in 4.341 seconds (process running for 4.917)  - w/
> CacheDataStore, Production Run
>
> I also got a crash on one attempt, I can't remember what I did to cause
> this unfortunately:
>
> Stack: [0x00007f3949ab0000,0x00007f3949bb0000],  sp=0x00007f3949bae628,
>  free space=1017k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V  [libjvm.so+0x42ca30]  ArchiveBuilder::get_buffered_addr(unsigned char*)
> const+0x40
> V  [libjvm.so+0xce4aa5]  VM_PopulateDumpSharedSpace::doit()+0x395
> V  [libjvm.so+0x100ae69]  VM_Operation::evaluate()+0x109
> V  [libjvm.so+0x100e348]  VMThread::evaluate_operation(VM_Operation*)+0xe8
> V  [libjvm.so+0x10142fb]  VMThread::inner_execute(VM_Operation*)+0x35b
> V  [libjvm.so+0x101460f]  VMThread::run()+0x16f
> V  [libjvm.so+0xf6e5cf]  Thread::call_run()+0x9f
> V  [libjvm.so+0xd74e13]  thread_native_entry(Thread*)+0x183
> C  [libc.so.6+0x98b07]
>
> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
> 0x0000000000000030
>
> Thinking ahead to operationalizing AOT, while a single-shot/on-exit
> workflow is great for iterating locally, requiring the VM to exit makes
> this more difficult to operationalize at scale:
>
>    1. We'll perform training and assembly on test, production canary and
>    production instances on behalf of application owners and handle
>    distribution of the archives. Depending on when we're able to perform a
>    training run, it'll have different benefits. i.e.:
>       1. Test environment will at least improve startup performance, with
>       a mixed benefit for warm up depending on the kind of traffic they take in
>       test
>       2. If an application uses canary deployments we'll have a full
>       production profile prior to the full production deployment, and all
>       instances will come up hot
>       3. If we reach production with only a test environment profile,
>       we'll perform a training run in production, so instances that scale up
>       following that run will come up hot (completely cold instances for an
>       initial deployment is less of a concern, because we deploy immutably and
>       get a natural warm-up period while we have 200% capacity online for a
>       cluster)
>    2. It's currently not a problem if a VM doesn't exit completely due to
>    a dangling non-daemon thread or hung shutdown hook
>
> Being able to trigger assembly/verification via jcmd without
> exiting, would make this far easier for us to support. If the overhead of
> the instrumentation for CDS can be avoided, being able to take a snapshot
> at any time on any VM would be better still, but that wouldn't be an
> impediment for us: we'll know that the instance will be used for training
> at boot time.
>
> We build nightlies of all the currently active OpenJDK projects, so if you
> land anything on premain between EA builds that you'd like us to try, let
> us know!
>
> Cheers,
> Danny
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240813/79540592/attachment.htm>

From duke at openjdk.org  Tue Aug 13 21:09:53 2024
From: duke at openjdk.org (duke)
Date: Tue, 13 Aug 2024 21:09:53 GMT
Subject: git: openjdk/leyden: premain: More AOTClassLinking clean up
Message-ID: <b4bf5d35-640d-4554-9b15-24e65110266d@openjdk.org>

Changeset: 65bd17a2
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-13 14:01:15 +0000
URL:       https://git.openjdk.org/leyden/commit/65bd17a22bfd484e0a3f12d97d7b6c02a99f0e72

More AOTClassLinking clean up

! src/hotspot/share/cds/aotClassLinker.cpp
! src/hotspot/share/cds/aotConstantPoolResolver.cpp
! src/hotspot/share/cds/aotConstantPoolResolver.hpp
! src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp
! src/hotspot/share/cds/aotLinkedClassBulkLoader.hpp
! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/archiveBuilder.hpp
! src/hotspot/share/cds/archiveUtils.cpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/filemap.hpp
! src/hotspot/share/cds/lambdaFormInvokers.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/classfile/vmClasses.cpp
! src/hotspot/share/logging/logTag.hpp
! src/hotspot/share/oops/constantPool.cpp
! src/hotspot/share/oops/cpCache.cpp
! src/hotspot/share/runtime/threads.cpp
! test/hotspot/jtreg/TEST.groups
! test/hotspot/jtreg/runtime/cds/appcds/ClassPathAttr.java
! test/hotspot/jtreg/runtime/cds/appcds/TestParallelGCWithCDS.java
! test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/AOTClassLinkingVMOptions.java
! test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/AOTClassLinkingVerification.java
! test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java
+ test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/InitiatingLoaderTester.jasm
! test/hotspot/jtreg/runtime/cds/appcds/jvmti/ClassFileLoadHookTest.java
! test/hotspot/jtreg/runtime/cds/appcds/leyden/LeydenAndOldClasses.java
! test/hotspot/jtreg/runtime/cds/appcds/leyden/LeydenGCFlags.java
! test/hotspot/jtreg/runtime/cds/appcds/resolvedConstants/ResolvedConstants.java
! test/lib/jdk/test/lib/cds/CDSTestUtils.java


From ioi.lam at oracle.com  Tue Aug 13 22:22:20 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Tue, 13 Aug 2024 15:22:20 -0700
Subject: EA feedback
In-Reply-To: <CAKt0pySHtZHSk0FyarM7kkdygTBppHBcYfpXPOfiJuS+7qjQyg@mail.gmail.com>
References: <CAABjz10oAmoLkEfLSLo0MN7+BzCFQJ5VYSkmhWH6GB6SVrF57Q@mail.gmail.com>
 <CAKt0pySHtZHSk0FyarM7kkdygTBppHBcYfpXPOfiJuS+7qjQyg@mail.gmail.com>
Message-ID: <bcf26ac8-663f-4b11-abb3-1ca942d506e2@oracle.com>


On 8/13/24 12:42 PM, Ashutosh Mehra wrote:
>
>     Being able to trigger assembly/verification via jcmd without
>     exiting,?would make this far easier for?us to support.
>
> There is a proposed enhancement for doing exactly this (and exploring 
> other ways to trigger end of training run); see 
> https://bugs.openjdk.org/browse/JDK-8335358


I am working on a prototype for dumping with jcmd. It will be similar to 
the existing "jcmd VM.cds statoc_dump" command, except that it will also 
support the dumping of the AOT cache and profile data.


Thanks

- Ioi


>
> Thanks,
> - Ashutosh Mehra
>
>
> On Fri, Aug 9, 2024 at 4:38?PM Danny Thomas <dannyt at netflix.com> wrote:
>
>     I tried?24-leydenpremain+2-8 on a few internal applications, some
>     quick feedback below (good to see you folks at the JVM LS!).
>
>     If a jar has a Class-Path attribute and?one or more of those
>     libraries are explicitly on the classpath, it causes the actual
>     and expected classpath to always differ. This is also the case
>     currently with CDS of course, but this feature is sure to be
>     deployed far more broadly than CDS is currently, so likely
>     something you want to look at:
>
>     [0.057s][info][class,path] non-existent Class-Path entry
>     lib/failureaccess-1.0.1.jar
>     [0.057s][info][class,path] opened:
>     lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
>     [0.057s][info][class,path] library =
>     lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
>
>     Startup time when training seems to be on par
>     with?ArchiveClassesAtExit in JDK 21, but it's?about a 3.5x startup
>     time penalty for one of our typical Spring Boot applications. From
>     a back-to-back run on my machine (AMD EPYC 9R14, 32 cores, 123G,
>     Ubuntu 22.04.4 LTS):
>
>     Started App in 7.698 seconds (process running for 8.229)
>     Started App in 26.247 seconds (process running for 29.262) - w/
>     CacheDataStore, Training Run
>     Started App in 4.341 seconds (process running for 4.917)??- w/
>     CacheDataStore, Production Run
>
>     I also got a crash on one attempt, I can't remember what I did to
>     cause this unfortunately:
>
>     Stack: [0x00007f3949ab0000,0x00007f3949bb0000],
>     ?sp=0x00007f3949bae628, ?free space=1017k
>     Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>     C=native code)
>     V ?[libjvm.so+0x42ca30]
>     ?ArchiveBuilder::get_buffered_addr(unsigned char*) const+0x40
>     V ?[libjvm.so+0xce4aa5] ?VM_PopulateDumpSharedSpace::doit()+0x395
>     V ?[libjvm.so+0x100ae69] ?VM_Operation::evaluate()+0x109
>     V ?[libjvm.so+0x100e348]
>     ?VMThread::evaluate_operation(VM_Operation*)+0xe8
>     V ?[libjvm.so+0x10142fb] ?VMThread::inner_execute(VM_Operation*)+0x35b
>     V ?[libjvm.so+0x101460f] ?VMThread::run()+0x16f
>     V ?[libjvm.so+0xf6e5cf] ?Thread::call_run()+0x9f
>     V ?[libjvm.so+0xd74e13] ?thread_native_entry(Thread*)+0x183
>     C ?[libc.so.6+0x98b07]
>
>     siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR),
>     si_addr: 0x0000000000000030
>
>     Thinking ahead to operationalizing AOT, while a
>     single-shot/on-exit workflow is great for iterating locally,
>     requiring the VM to exit makes this more difficult to
>     operationalize at scale:
>
>      1. We'll perform training and assembly on test, production canary
>         and production instances on behalf of application owners and
>         handle distribution of the archives. Depending on when we're
>         able to perform a training run, it'll have different benefits.
>         i.e.:
>          1. Test environment will at least improve startup
>             performance, with a mixed benefit for warm up depending on
>             the kind of traffic they take in test
>          2. If an application uses canary deployments we'll have a
>             full production profile prior to the full production
>             deployment, and all instances will come up hot
>          3. If we reach production with only a test environment
>             profile, we'll perform a training run in production, so
>             instances that scale up following that run will come up
>             hot (completely cold instances for an initial deployment
>             is less of a concern, because we deploy immutably and get
>             a natural warm-up period while we have 200% capacity
>             online for a cluster)
>      2. It's currently not a problem if a VM doesn't exit completely
>         due to a dangling non-daemon thread or hung shutdown hook
>
>     Being able to trigger assembly/verification via jcmd without
>     exiting,?would make this far easier for?us to support. If the
>     overhead of the instrumentation for CDS can?be avoided, being able
>     to take a snapshot at any time on any VM would be better still,
>     but that wouldn't be an impediment for us:?we'll know that the
>     instance will be used for training at boot time.
>
>     We build nightlies of all the currently active OpenJDK projects,
>     so if you land anything on premain between EA builds that you'd
>     like us to try, let us know!
>
>     Cheers,
>     Danny
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240813/3717637f/attachment.htm>

From duke at openjdk.org  Wed Aug 14 00:49:03 2024
From: duke at openjdk.org (duke)
Date: Wed, 14 Aug 2024 00:49:03 GMT
Subject: git: openjdk/leyden: premain: 277 new changesets
Message-ID: <124d506e-e47e-4256-bcd6-beca95ce7490@openjdk.org>

Changeset: b44632aa
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-18 21:46:07 +0000
URL:       https://git.openjdk.org/leyden/commit/b44632aa15d21a10e559aee02a9e4dcd876654f6

8336588: Ensure Transform downstream receives upstream start items only after downstream started

Reviewed-by: asotona

! src/java.base/share/classes/jdk/internal/classfile/impl/TransformImpl.java
! test/jdk/jdk/classfile/TransformTests.java

Changeset: 902c2afb
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-18 21:46:19 +0000
URL:       https://git.openjdk.org/leyden/commit/902c2afb6714f778e3229c8411e9f9d5c392b388

8336585: BoundAttribute.readEntryList not type-safe

Reviewed-by: asotona

! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java
! test/jdk/jdk/classfile/BoundAttributeTest.java

Changeset: 39f44768
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-18 22:22:59 +0000
URL:       https://git.openjdk.org/leyden/commit/39f44768131254ee11f723f92e2bac57b0d1ade0

8334772: Change Class::signers to an explicit field

Reviewed-by: dholmes, alanb, rriggs, coleenp

! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/include/jvm.h
! src/hotspot/share/prims/jvm.cpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/native/libjava/Class.c

Changeset: 330e520c
Branch: premain
Author:    Fernando Guallini <fguallini at openjdk.org>
Date:      2024-07-18 22:36:26 +0000
URL:       https://git.openjdk.org/leyden/commit/330e520c1d42d3a9f3e187873dcd8ed7fd561aaf

8028127: Regtest java/security/Security/SynchronizedAccess.java is incorrect

Reviewed-by: wetmore, mdonovan, rhalade

! test/jdk/java/security/Security/SynchronizedAccess.java

Changeset: 1b9270ac
Branch: premain
Author:    Prajwal Kumaraswamy <pkumaraswamy at openjdk.org>
Committer: Bradford Wetmore <wetmore at openjdk.org>
Date:      2024-07-18 22:42:34 +0000
URL:       https://git.openjdk.org/leyden/commit/1b9270ac8a76b482103dd3f6b12606a22214e554

8328723: IP Address error when client enables HTTPS endpoint check on server socket

Reviewed-by: wetmore, djelinski

! src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java

Changeset: 902bada2
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-07-19 02:56:42 +0000
URL:       https://git.openjdk.org/leyden/commit/902bada2cdd141ade8615d1e3c2fcbff2b80e3b1

8234071: JTable.AUTO_RESIZE_LAST_COLUMN acts like AUTO_RESIZE_ALL_COLUMNS

Reviewed-by: prr, abhiscxk

! src/java.desktop/share/classes/javax/swing/JTable.java

Changeset: f5871df2
Branch: premain
Author:    Andrey Turbanov <aturbanov at openjdk.org>
Date:      2024-07-19 05:54:25 +0000
URL:       https://git.openjdk.org/leyden/commit/f5871df25c60990825babb3bbae38c5ade93f097

8336675: Remove UnixFileSystemProvider.checkPath in favor of UnixPath.toUnixPath

Reviewed-by: jpai, alanb, bpb

! src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java

Changeset: 10fcad70
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-07-19 06:23:11 +0000
URL:       https://git.openjdk.org/leyden/commit/10fcad70b3894023d65716b42dc67c1a2bda9c03

8325945: Error reporting should limit the number of String characters printed

Reviewed-by: thartmann, stuefe

! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/globals.hpp
+ test/hotspot/jtreg/runtime/PrintingTests/StringPrinting.java
! test/lib/jdk/test/whitebox/WhiteBox.java

Changeset: fa5ad700
Branch: premain
Author:    SendaoYan <syan at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2024-07-19 07:06:51 +0000
URL:       https://git.openjdk.org/leyden/commit/fa5ad700bb6a92aef7577969e09b4fbd93feb388

8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137

Reviewed-by: lmesnik, sspitsyn

! test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java
! test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java

Changeset: 10982fe5
Branch: premain
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2024-07-19 07:28:51 +0000
URL:       https://git.openjdk.org/leyden/commit/10982fe557e9e8b68b674630a9979cb355bdbe62

8335843: C2 hits assert(_print_inlining_stream->size() > 0) failed: missing inlining msg

Reviewed-by: thartmann, kvn, vlivanov

! src/hotspot/share/opto/callGenerator.cpp
+ test/hotspot/jtreg/compiler/print/TestPrintInliningLateMHCall.java
! test/hotspot/jtreg/compiler/print/TestPrintInliningLateVirtualCall.java

Changeset: 0ddf54e2
Branch: premain
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2024-07-19 07:30:23 +0000
URL:       https://git.openjdk.org/leyden/commit/0ddf54e222104469669f611804ae55e2685f54fb

8335709: C2: assert(!loop->is_member(get_loop(useblock))) failed: must be outside loop

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

! src/hotspot/share/opto/loopnode.cpp
+ test/hotspot/jtreg/compiler/loopopts/InfiniteLoopBadControlNeverBranch.java

Changeset: b703be9c
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-07-19 08:34:36 +0000
URL:       https://git.openjdk.org/leyden/commit/b703be9cf633796456991279d07cbde98ad7f1aa

8336465: C2: EA incorrectly/unnecessarily checks for clinits

Reviewed-by: kvn, thartmann

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

Changeset: 5d965f36
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-07-19 08:34:47 +0000
URL:       https://git.openjdk.org/leyden/commit/5d965f36d3cd7a1a1f22bf119a98a9e9576a647f

8336466: C2: Parser incorrectly/unnecessarily checks for clinits

Reviewed-by: kvn, thartmann

! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/parse1.cpp

Changeset: 84bc4767
Branch: premain
Author:    Volker Simonis <simonis at openjdk.org>
Date:      2024-07-19 11:26:44 +0000
URL:       https://git.openjdk.org/leyden/commit/84bc4767a4cd68fb52a36c6644bbec67c24b0e1d

8336258: Document the behavior of 'exclude' and 'compileonly' with respect to inlining

Reviewed-by: thartmann, jkarthikeyan

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

Changeset: 6e9fcc2d
Branch: premain
Author:    Jie Fu <jiefu at openjdk.org>
Date:      2024-07-19 12:28:56 +0000
URL:       https://git.openjdk.org/leyden/commit/6e9fcc2d80170c79e45b8710e98754c67d544012

8336816: runtime/PrintingTests/StringPrinting.java fails with release VMs

Reviewed-by: dholmes

! test/hotspot/jtreg/runtime/PrintingTests/StringPrinting.java

Changeset: c25c4896
Branch: premain
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-07-19 13:09:45 +0000
URL:       https://git.openjdk.org/leyden/commit/c25c4896ad9ef031e3cddec493aef66ff87c48a7

8333812: ClassFile.verify() can throw exceptions instead of returning VerifyErrors

Reviewed-by: liach

! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java
! test/jdk/jdk/classfile/VerifierSelfTest.java

Changeset: 3ade2b61
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-19 21:25:20 +0000
URL:       https://git.openjdk.org/leyden/commit/3ade2b6114bbe81eb03e3a49c08b5401f70a2367

8336777: BufferedMethodBuilder not initialized with static flag

Reviewed-by: asotona

! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedClassBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectMethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/MethodInfo.java
! src/java.base/share/classes/jdk/internal/classfile/impl/TerminalMethodBuilder.java
+ test/jdk/jdk/classfile/MethodBuilderStaticFlagTest.java

Changeset: 939fe000
Branch: premain
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2024-07-19 21:52:45 +0000
URL:       https://git.openjdk.org/leyden/commit/939fe000a96bc7c92c7b8814eb6ee66856718e4e

8336786: VerifyError with lambda capture and enclosing instance references

Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/langtools/tools/javac/lambda/SuperClassThisCapture/SuperClassThisCapture.java
= test/langtools/tools/javac/lambda/SuperClassThisCapture/a/A.java

Changeset: e7e48a78
Branch: premain
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-07-19 21:53:04 +0000
URL:       https://git.openjdk.org/leyden/commit/e7e48a780a34007994f830869fdb74ba1cb5b3fe

8248609: [Graal] vmTestbase/nsk/jdi/VoidValue/toString/tostring001/TestDescription.java failed with Unexpected com.sun.jdi.ObjectCollectedException

Reviewed-by: amenkov, lmesnik

! test/hotspot/jtreg/vmTestbase/nsk/jdi/VoidValue/toString/tostring001.java

Changeset: e3acf4c6
Branch: premain
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-07-19 22:06:23 +0000
URL:       https://git.openjdk.org/leyden/commit/e3acf4c627c3c75f9a2ef29647daa6f4746fdc62

8336792: DateTimeFormatterBuilder append zeros based on StringBuilder.repeat

Reviewed-by: liach, rriggs, naoto

! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java

Changeset: 491b9f5e
Branch: premain
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-07-20 06:54:19 +0000
URL:       https://git.openjdk.org/leyden/commit/491b9f5efc01fa36fb3c174e130b46bc69c8d707

8336706: Optimize LocalDate.toString with StringBuilder.repeat

Reviewed-by: liach, rriggs

! src/java.base/share/classes/java/time/LocalDate.java

Changeset: c5b7af73
Branch: premain
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-07-20 15:41:29 +0000
URL:       https://git.openjdk.org/leyden/commit/c5b7af73d07f7458e970f5752eb75640562ddc7b

8336692: Redo fix for JDK-8284620

Reviewed-by: dlong

! src/hotspot/share/asm/codeBuffer.cpp

Changeset: b21cb44e
Branch: premain
Author:    Aleksei Efimov <aefimov at openjdk.org>
Date:      2024-07-20 16:48:30 +0000
URL:       https://git.openjdk.org/leyden/commit/b21cb44e38ee8ea75e3a1c51e3a28388056a492d

8329398: Links in InetAddress class description show "#format"

Reviewed-by: jpai

! src/java.base/share/classes/java/net/InetAddress.java

Changeset: ad498f57
Branch: premain
Author:    Christian Stein <cstein at openjdk.org>
Date:      2024-07-21 08:49:16 +0000
URL:       https://git.openjdk.org/leyden/commit/ad498f57fcead174306c6e6e3b2d1f9916821b84

8335896: Source launcher should set TCCL

Reviewed-by: alanb

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

Changeset: fd741a88
Branch: premain
Author:    Hai-May Chao <hchao at openjdk.org>
Date:      2024-07-21 17:05:46 +0000
URL:       https://git.openjdk.org/leyden/commit/fd741a88e8bc73a9db6d4283bb54daab1760b442

8327538: The SSLExtension class specifies incorrect values for heartbeat per RFC 6520 and post_handshake_auth per RFC 8446

Reviewed-by: wetmore

! src/java.base/share/classes/sun/security/ssl/SSLExtension.java

Changeset: 4da99158
Branch: premain
Author:    lingjun.cg <lingjun.cg at alibaba-inc.com>
Date:      2024-07-22 02:01:08 +0000
URL:       https://git.openjdk.org/leyden/commit/4da99158754c25c5d0650f2d042aad3e94a9b0c5

8333396: Use StringBuilder internally for java.text.Format.* formatting

Reviewed-by: naoto, liach, jlu

! src/java.base/share/classes/java/text/CharacterIteratorFieldDelegate.java
! src/java.base/share/classes/java/text/ChoiceFormat.java
! src/java.base/share/classes/java/text/CompactNumberFormat.java
! src/java.base/share/classes/java/text/DateFormat.java
! src/java.base/share/classes/java/text/DecimalFormat.java
! src/java.base/share/classes/java/text/DontCareFieldPosition.java
! src/java.base/share/classes/java/text/FieldPosition.java
! src/java.base/share/classes/java/text/Format.java
! src/java.base/share/classes/java/text/ListFormat.java
! src/java.base/share/classes/java/text/MessageFormat.java
! src/java.base/share/classes/java/text/NumberFormat.java
! src/java.base/share/classes/java/text/SimpleDateFormat.java
+ src/java.base/share/classes/java/text/StringBufFactory.java
+ test/micro/org/openjdk/bench/java/text/DateFormatterBench.java
+ test/micro/org/openjdk/bench/java/text/ListFormatterBench.java
+ test/micro/org/openjdk/bench/java/text/MessageFormatterBench.java

Changeset: 0db6c15e
Branch: premain
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-07-22 07:33:29 +0000
URL:       https://git.openjdk.org/leyden/commit/0db6c15efe255bd313fb2b827d2ee05171e62ae9

8336833: Endless loop in Javap ClassWriter

Reviewed-by: liach

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

Changeset: c1fdc04a
Branch: premain
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Date:      2024-07-22 10:29:34 +0000
URL:       https://git.openjdk.org/leyden/commit/c1fdc04ad78e6e4712f2173370012106f9cc45ee

8336781: Erroneous exhaustivity check with boolean switch

Reviewed-by: vromero

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

Changeset: 7ddd0259
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-07-22 13:19:30 +0000
URL:       https://git.openjdk.org/leyden/commit/7ddd02599c4cb85fdc0a1f0a7c4ce37a09efe16e

4265389: JSplitPane does not support ComponentOrientation

Reviewed-by: tr, abhiscxk

! src/java.desktop/share/classes/javax/swing/JSplitPane.java
+ test/jdk/javax/swing/JSplitPane/TestSplitPaneOrientationTest.java

Changeset: 92de2b2d
Branch: premain
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-07-22 13:27:12 +0000
URL:       https://git.openjdk.org/leyden/commit/92de2b2d5f21af38380b437af51e49c7ac142258

8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation

Reviewed-by: liach, djelinski

! src/java.base/share/classes/java/lang/classfile/components/CodeStackTracker.java
! src/java.base/share/classes/java/lang/classfile/package-info.java
! src/java.base/share/classes/java/lang/foreign/Arena.java
! src/java.base/share/classes/java/lang/foreign/MemorySegment.java
! src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
! src/java.base/share/classes/java/net/spi/InetAddressResolver.java
! src/java.base/share/classes/java/text/MessageFormat.java
! src/java.base/share/classes/javax/security/auth/Subject.java

Changeset: c3226aae
Branch: premain
Author:    Weijun Wang <weijun at openjdk.org>
Date:      2024-07-22 13:43:55 +0000
URL:       https://git.openjdk.org/leyden/commit/c3226aaeb810521257e961be5763552c86ee5651

8334394: Race condition in Class::protectionDomain

Reviewed-by: liach, jpai, rriggs, alanb

! src/java.base/share/classes/java/lang/Class.java
+ test/jdk/java/lang/Class/ProtectionDomainRace.java

Changeset: 0725eb1d
Branch: premain
Author:    Daniel Lund?n <dlunden at openjdk.org>
Date:      2024-07-22 14:41:40 +0000
URL:       https://git.openjdk.org/leyden/commit/0725eb1df2357bb0489e2521d96bb424fc233406

8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp

Reviewed-by: cjplummer, kvn, thartmann

! test/hotspot/jtreg/serviceability/sa/ClhsdbDumpheap.java

Changeset: c740e1e3
Branch: premain
Author:    Weijun Wang <weijun at openjdk.org>
Date:      2024-07-22 16:00:40 +0000
URL:       https://git.openjdk.org/leyden/commit/c740e1e3b080d43cf9871853538f233843d1b81c

8333772: Incorrect Kerberos behavior when udp_preference_limit = 0

Reviewed-by: ssahoo, mullan

! src/java.security.jgss/share/classes/sun/security/krb5/KdcComm.java
! src/java.security.jgss/share/classes/sun/security/krb5/internal/Krb5.java
! test/jdk/sun/security/krb5/auto/KdcPolicy.java
+ test/jdk/sun/security/krb5/auto/RealmSpecificValues.java

Changeset: 7ea77305
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-07-22 16:40:34 +0000
URL:       https://git.openjdk.org/leyden/commit/7ea773056433c467dbd321a0a063f4789552ef89

8332551: Test vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java timed out

Reviewed-by: sspitsyn, lmesnik

! test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java

Changeset: c1c97042
Branch: premain
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-07-22 17:17:46 +0000
URL:       https://git.openjdk.org/leyden/commit/c1c9704268e9e651cd82c8550913d8ac60aa494a

8336479: Provide Process.waitFor(Duration)

Reviewed-by: liach, jpai, rriggs

! src/java.base/share/classes/java/lang/Process.java
+ test/jdk/java/lang/Process/WaitForDuration.java
! test/lib/jdk/test/lib/process/ProcessTools.java

Changeset: 8438c585
Branch: premain
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2024-07-22 17:20:58 +0000
URL:       https://git.openjdk.org/leyden/commit/8438c5853f4ae5cef4e861cd0b3952371c886f45

8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and ZIP64_EXTID

Reviewed-by: jpai, vtewari, lancea

! src/java.base/share/classes/java/util/zip/ZipConstants64.java
! src/java.base/share/classes/java/util/zip/ZipFile.java
! src/java.base/share/classes/java/util/zip/ZipInputStream.java
! src/java.base/share/classes/java/util/zip/ZipOutputStream.java
! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipConstants.java
! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java

Changeset: 31a85f17
Branch: premain
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2024-07-22 17:25:42 +0000
URL:       https://git.openjdk.org/leyden/commit/31a85f17440ca0d791f694d670119ba8adc1ba7f

8336491: Unnecessary boxing conversions in void-returning lambdas

Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/langtools/tools/javac/lambda/VoidReturnBoxing.java

Changeset: 34eea6a5
Branch: premain
Author:    Henry Lin <hny at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-07-22 17:29:12 +0000
URL:       https://git.openjdk.org/leyden/commit/34eea6a5fa27121bc0e9e8ace0894833d4a9f826

8333088: ubsan: shenandoahAdaptiveHeuristics.cpp:245:44: runtime error: division by zero

Reviewed-by: shade, rkennke

! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp

Changeset: b5575942
Branch: premain
Author:    Henry Lin <hny at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-07-22 17:29:27 +0000
URL:       https://git.openjdk.org/leyden/commit/b5575942027281166676678e2081b024ec572644

8333728: ubsan: shenandoahFreeSet.cpp:1347:24: runtime error: division by zero

Reviewed-by: shade, rkennke

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

Changeset: b144910e
Branch: premain
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-07-22 18:56:30 +0000
URL:       https://git.openjdk.org/leyden/commit/b144910ebb74be5a12dae57263f2a93452535f02

8334145: <pid> missing from vm_memory_map_<pid>.txt in System.dump_map help text

Reviewed-by: dholmes, stuefe

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

Changeset: ed649944
Branch: premain
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-07-22 19:34:09 +0000
URL:       https://git.openjdk.org/leyden/commit/ed6499446dadc339599271a282ceca4a52dbeed4

8333391: Test com/sun/jdi/InterruptHangTest.java failed: Thread was never interrupted during sleep

Reviewed-by: lmesnik, amenkov

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

Changeset: d63d6e23
Branch: premain
Author:    Weijun Wang <weijun at openjdk.org>
Date:      2024-07-22 22:17:43 +0000
URL:       https://git.openjdk.org/leyden/commit/d63d6e23d123e82cef1372aed31b5846fb6d23fd

8336935: Test sun/security/krb5/auto/RealmSpecificValues.java fails: java.lang.RuntimeException: Should not reach here

Reviewed-by: hchao, dholmes

! test/jdk/sun/security/krb5/auto/RealmSpecificValues.java

Changeset: 96e4a187
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-22 22:53:52 +0000
URL:       https://git.openjdk.org/leyden/commit/96e4a1876a3ab0819c017ba9b634711fe19e58c3

8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException when a component class cannot be resolved

Reviewed-by: jvernee

! src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java
! test/jdk/java/lang/constant/MethodTypeDescTest.java

Changeset: aabec4a9
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-22 22:54:36 +0000
URL:       https://git.openjdk.org/leyden/commit/aabec4a947ed2a808a1443fa6b2dabedd8c2dd9f

8335922: Incorrect @Stable usage of LambdaForm$Name.index

Reviewed-by: jvernee, shade

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

Changeset: 22914e07
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-23 04:59:58 +0000
URL:       https://git.openjdk.org/leyden/commit/22914e0774f5bb8ded3d825bea1dc312b12d4d4a

8335938: Review XxxBuilder.original and XxxModel.parent

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
! src/java.base/share/classes/java/lang/classfile/FieldBuilder.java
! src/java.base/share/classes/java/lang/classfile/MethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractDirectBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedFieldBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedClassBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedFieldBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedMethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/NonterminalCodeBuilder.java

Changeset: 9f03f687
Branch: premain
Author:    Alan Bateman <alanb at openjdk.org>
Date:      2024-07-23 05:13:49 +0000
URL:       https://git.openjdk.org/leyden/commit/9f03f687556ee61436a1cb8c89ff063a7cbeaa51

8336339: (se) SelectionKey.interestOps(int) should not throw ClosedSelectorException

Reviewed-by: jpai, bpb

! src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java
! src/java.base/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java
! src/java.base/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java
! src/java.base/share/classes/sun/nio/ch/SelectorImpl.java
! src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java
! src/java.base/windows/classes/sun/nio/ch/WEPollSelectorImpl.java
! src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java
+ test/jdk/java/nio/channels/Selector/RaceUpdatesAndClose.java

Changeset: 48030a2a
Branch: premain
Author:    SendaoYan <syan at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2024-07-23 05:23:48 +0000
URL:       https://git.openjdk.org/leyden/commit/48030a2a8670e6274abb6c77f19dd3d92517e888

8336855: Duplicate protected declaration and comment in interp_masm_aarch64.hpp

Reviewed-by: jiefu, shade

! src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp

Changeset: 4c7b3e7f
Branch: premain
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
Date:      2024-07-23 07:43:57 +0000
URL:       https://git.openjdk.org/leyden/commit/4c7b3e7fc39a06e208ea1668095d055457549d63

8334758: Incorrect note in Javadoc for a few RandomGenerator methods

Reviewed-by: bpb

! src/java.base/share/classes/java/util/random/RandomGenerator.java

Changeset: e83b4b23
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-07-23 11:50:57 +0000
URL:       https://git.openjdk.org/leyden/commit/e83b4b236eca48d0b75094006f7f888398194fe4

8335182: Consolidate and streamline String concat code shapes

Reviewed-by: liach, jvernee

! src/java.base/share/classes/java/lang/StringConcatHelper.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! test/micro/org/openjdk/bench/java/lang/StringConcat.java
+ test/micro/org/openjdk/bench/java/lang/StringConcatStartup.java

Changeset: a2a236f9
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-23 12:11:47 +0000
URL:       https://git.openjdk.org/leyden/commit/a2a236f9041083e4b8f11e068da0031dd5f52c2b

8335939: Hide element writing across the ClassFile API

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/Annotation.java
! src/java.base/share/classes/java/lang/classfile/AnnotationElement.java
! src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
! src/java.base/share/classes/java/lang/classfile/Attribute.java
! src/java.base/share/classes/java/lang/classfile/BootstrapMethodEntry.java
! src/java.base/share/classes/java/lang/classfile/BufWriter.java
! src/java.base/share/classes/java/lang/classfile/ClassFileElement.java
! src/java.base/share/classes/java/lang/classfile/ClassReader.java
! src/java.base/share/classes/java/lang/classfile/CustomAttribute.java
! src/java.base/share/classes/java/lang/classfile/FieldModel.java
! src/java.base/share/classes/java/lang/classfile/MethodModel.java
- src/java.base/share/classes/java/lang/classfile/WritableElement.java
! src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java
! src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
! src/java.base/share/classes/java/lang/classfile/instruction/LocalVariable.java
! src/java.base/share/classes/java/lang/classfile/instruction/LocalVariableType.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractAttributeMapper.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractBoundLocalVariable.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPseudoInstruction.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractUnboundModel.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BootstrapMethodEntryImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedFieldBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectClassBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectFieldBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectMethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/FieldImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/MethodImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java
! src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java
! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
! src/java.base/share/classes/jdk/internal/classfile/impl/TemporaryConstantPool.java
! src/java.base/share/classes/jdk/internal/classfile/impl/UnboundAttribute.java
! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java
! test/jdk/jdk/classfile/BoundAttributeTest.java
! test/jdk/jdk/classfile/CorpusTest.java
! test/jdk/jdk/classfile/LimitsTest.java
! test/jdk/jdk/classfile/LowAdaptTest.java
! test/jdk/jdk/classfile/VerifierSelfTest.java
! test/langtools/tools/javac/classfiles/attributes/AnnotationDefault/AnnotationDefaultVerifier.java

Changeset: 0e555b5d
Branch: premain
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
Date:      2024-07-23 12:22:53 +0000
URL:       https://git.openjdk.org/leyden/commit/0e555b5ded819cc3b363673320dc848c321861ce

8204582: Extra spaces in jlink documentation make it incorrect.

Reviewed-by: alanb

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

Changeset: 8e1f17e3
Branch: premain
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
Date:      2024-07-23 15:49:34 +0000
URL:       https://git.openjdk.org/leyden/commit/8e1f17e351bc7949b318a0542a4a4cb30ead5a97

8327054: DiagnosticCommand Compiler.perfmap does not log on output()

Reviewed-by: lmesnik, stuefe, kevinw, cjplummer

! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/codeCache.hpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/services/diagnosticCommand.cpp
! test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java

Changeset: 8efcb40c
Branch: premain
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-07-23 16:27:09 +0000
URL:       https://git.openjdk.org/leyden/commit/8efcb40c47d8730d84620a9e980ab9eeb5f51441

8335823: Update --release 23 symbol information for JDK 23 build 33

Reviewed-by: iris, liach

! src/jdk.compiler/share/data/symbols/java.base-N.sym.txt

Changeset: 2f2223d7
Branch: premain
Author:    William Kemper <wkemper at openjdk.org>
Date:      2024-07-23 16:50:25 +0000
URL:       https://git.openjdk.org/leyden/commit/2f2223d7524c4405cc7ca6ab77da62016bbfa911

8336944: Shenandoah: Should only relativize stack chunks for successful evacuations

Reviewed-by: shade, ysr

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

Changeset: 4c91d5cb
Branch: premain
Author:    Ben Perez <ben.perez at oracle.com>
Committer: Sean Mullan <mullan at openjdk.org>
Date:      2024-07-23 19:35:11 +0000
URL:       https://git.openjdk.org/leyden/commit/4c91d5cb4176e5f4970dc00835d802d857390d72

8322133: getParameterSpec(ECGenParameterSpec.class) on EC AlgorithmParameters  does not return standard names

Reviewed-by: mullan

! src/java.base/share/classes/sun/security/util/ECParameters.java
+ test/jdk/com/sun/crypto/provider/AlgorithmParameters/EC/CurveGetParameterSpec.java

Changeset: 476d2ae6
Branch: premain
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-07-23 20:21:08 +0000
URL:       https://git.openjdk.org/leyden/commit/476d2ae69d6f67fdf9e2a9353f224141318690f2

8336831: Optimize StringConcatHelper.simpleConcat

Reviewed-by: liach, redestad, rriggs

! src/java.base/share/classes/java/lang/String.java
! src/java.base/share/classes/java/lang/StringConcatHelper.java

Changeset: 3251eea1
Branch: premain
Author:    Martin Balao <mbalao at openjdk.org>
Date:      2024-07-24 02:39:35 +0000
URL:       https://git.openjdk.org/leyden/commit/3251eea1f4289a0505052be204407c02ca38b0ad

8336499: Failure when creating non-CRT RSA private keys in SunPKCS11

Co-authored-by: Francisco Ferrari Bihurriet <fferrari at openjdk.org>
Co-authored-by: Martin Balao <mbalao at openjdk.org>
Reviewed-by: fferrari, valeriep

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

Changeset: 5b4824cf
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-07-24 07:21:45 +0000
URL:       https://git.openjdk.org/leyden/commit/5b4824cf9aba297fa6873ebdadc0e9545647e90d

8336827: compiler/vectorization/TestFloat16VectorConvChain.java  timeouts on ppc64 platforms after JDK-8335860

Reviewed-by: kvn, mdoerr, shade

! test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java

Changeset: 05d88de0
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-07-24 09:10:38 +0000
URL:       https://git.openjdk.org/leyden/commit/05d88de05e9b7814ecd5517aacd17f0feafdff3c

8336098: G1: Refactor G1RebuildRSAndScrubTask

Reviewed-by: tschatzl, gli

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

Changeset: 332df83e
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-24 12:13:15 +0000
URL:       https://git.openjdk.org/leyden/commit/332df83e7cb1f272c08f8e4955d6abaf3f091ace

8336927: Missing equals and hashCode in java.lang.classfile.Annotation

Reviewed-by: asotona

! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationImpl.java
! test/jdk/jdk/classfile/AnnotationTest.java

Changeset: aa15b895
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-07-24 15:12:53 +0000
URL:       https://git.openjdk.org/leyden/commit/aa15b895c96fd62152d5ae5a1a9dfd28610c5125

8336485: jdk/jfr/jcmd/TestJcmdView.java RuntimeException: 'Invoked Concurrent' missing from stdout/stderr

Reviewed-by: mgronlun

! test/jdk/jdk/jfr/jcmd/TestJcmdView.java

Changeset: b2599f8b
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-07-24 15:13:02 +0000
URL:       https://git.openjdk.org/leyden/commit/b2599f8b0ed227f7b67fbbb77b4a5af1f12730e2

8336316: JFR: Use SettingControl::getValue() instead of setValue() for ActiveSetting event

Reviewed-by: mgronlun

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

Changeset: 04e8cb86
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-07-24 15:43:53 +0000
URL:       https://git.openjdk.org/leyden/commit/04e8cb8641bfdad717b368c087619905bccdf5e6

8336815: Several methods in java.net.Socket and ServerSocket do not specify behavior when already bound, connected or closed

Reviewed-by: alanb

! src/java.base/share/classes/java/net/ServerSocket.java
! src/java.base/share/classes/java/net/Socket.java
+ test/jdk/java/net/ServerSocket/ClosedServerSocketTest.java
+ test/jdk/java/net/Socket/ClosedSocketTest.java

Changeset: 4ea4d7c6
Branch: premain
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-07-24 16:48:34 +0000
URL:       https://git.openjdk.org/leyden/commit/4ea4d7c68444200ab38cbd76762c2f27848e264e

8336679: Add @implSpec for the default implementations in Process.waitFor()

Reviewed-by: bpb, jlu, liach

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

Changeset: 9e8e3595
Branch: premain
Author:    Justin Lu <jlu at openjdk.org>
Date:      2024-07-24 20:08:13 +0000
URL:       https://git.openjdk.org/leyden/commit/9e8e359513cf15faf549b12ced947d3a78e544aa

8336787: Examine java.text.Format API for implSpec usage

Reviewed-by: liach

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

Changeset: 5a8861a3
Branch: premain
Author:    Justin Lu <jlu at openjdk.org>
Date:      2024-07-24 20:14:00 +0000
URL:       https://git.openjdk.org/leyden/commit/5a8861a3a1b436ce7414176c095c58c9a1e038d6

8336847: Use pattern match switch in NumberFormat classes

Reviewed-by: liach, naoto

! src/java.base/share/classes/java/text/CompactNumberFormat.java
! src/java.base/share/classes/java/text/DecimalFormat.java
! src/java.base/share/classes/java/text/NumberFormat.java

Changeset: e716f5ed
Branch: premain
Author:    Andrey Turbanov <aturbanov at openjdk.org>
Date:      2024-07-24 20:26:11 +0000
URL:       https://git.openjdk.org/leyden/commit/e716f5ed53c20f4235787e2d6927a16ebcf67b8f

8336755: Remove unused UNALIGNED field from view buffers

Reviewed-by: alanb, liach, bpb

! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template

Changeset: 021c2c36
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-07-24 21:15:18 +0000
URL:       https://git.openjdk.org/leyden/commit/021c2c36ac243009c71147072d405636cab0b12c

8337067: Test runtime/classFileParserBug/Bad_NCDFE_Msg.java won't compile

Reviewed-by: lfoltan

! test/hotspot/jtreg/runtime/classFileParserBug/Bad_NCDFE_Msg.java

Changeset: 24f67d02
Branch: premain
Author:    Neethu Prasad <nprasad at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-07-24 22:22:18 +0000
URL:       https://git.openjdk.org/leyden/commit/24f67d0254c08a668d24f28ec0fa768ef10feed5

8334232: Optimize C1 classes layout

Reviewed-by: phh, kvn

! src/hotspot/share/c1/c1_Instruction.hpp
! src/hotspot/share/c1/c1_LIR.cpp
! src/hotspot/share/c1/c1_LIR.hpp

Changeset: 0898ab7f
Branch: premain
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-07-24 22:39:49 +0000
URL:       https://git.openjdk.org/leyden/commit/0898ab7f7496689e5de52a5dc4530ca21def1fca

8336741: Optimize LocalTime.toString with StringBuilder.repeat

Reviewed-by: liach, rriggs, naoto

! src/java.base/share/classes/java/time/LocalTime.java
! src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
+ test/micro/org/openjdk/bench/java/time/ToStringBench.java

Changeset: d3e51daf
Branch: premain
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2024-07-25 01:35:03 +0000
URL:       https://git.openjdk.org/leyden/commit/d3e51daf7331b84b4e78f7f10360848d7c549c1a

8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be

Reviewed-by: dholmes, pchilanomate

! src/hotspot/share/runtime/continuationFreezeThaw.cpp
! test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java

Changeset: 6e228ce3
Branch: premain
Author:    Alan Bateman <alanb at openjdk.org>
Date:      2024-07-25 04:59:01 +0000
URL:       https://git.openjdk.org/leyden/commit/6e228ce382d1fad6cba0d0df8a507e6bd32a9a4a

8336254: Virtual thread implementation + test updates

Reviewed-by: sspitsyn, kevinw

! make/test/JtregNativeHotspot.gmk
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/VirtualThread.java
! src/java.base/share/classes/java/util/concurrent/locks/LockSupport.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
- src/java.base/share/classes/jdk/internal/misc/VirtualThreads.java
! test/hotspot/jtreg/serviceability/jvmti/thread/GetFrameCount/framecnt01/framecnt01.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/VThreadEventTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/libVThreadEventTest.cpp
+ test/jdk/java/lang/Thread/virtual/CarrierThreadInfo.java
- test/jdk/java/lang/Thread/virtual/CarrierThreadWaits.java
! test/jdk/java/lang/Thread/virtual/CustomScheduler.java
- test/jdk/java/lang/Thread/virtual/GetStackTrace.java
- test/jdk/java/lang/Thread/virtual/GetStackTraceWhenRunnable.java
! test/jdk/java/lang/Thread/virtual/JfrEvents.java
+ test/jdk/java/lang/Thread/virtual/MonitorEnterExit.java
! test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java
! test/jdk/java/lang/Thread/virtual/ParkWithFixedThreadPool.java
! test/jdk/java/lang/Thread/virtual/Reflection.java
+ test/jdk/java/lang/Thread/virtual/StackFrames.java
- test/jdk/java/lang/Thread/virtual/StackTraces.java
! test/jdk/java/lang/Thread/virtual/ThreadAPI.java
- test/jdk/java/lang/Thread/virtual/ThreadBuilders.java
! test/jdk/java/lang/Thread/virtual/VirtualThreadPinnedEventThrows.java
+ test/jdk/java/lang/Thread/virtual/stress/CompletableFutureTimedGet.java
- test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALot.java
+ test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking.java
+ test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenParking.java
! test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java
! test/jdk/java/lang/Thread/virtual/stress/PinALot.java
! test/jdk/java/lang/Thread/virtual/stress/PingPong.java
! test/jdk/java/lang/Thread/virtual/stress/Skynet.java
! test/jdk/java/lang/Thread/virtual/stress/SleepALot.java
- test/jdk/java/lang/Thread/virtual/stress/TimedGet.java
+ test/jdk/java/lang/Thread/virtual/stress/TimedWaitALot.java
! test/jdk/java/lang/Thread/virtual/stress/YieldALot.java
+ test/jdk/java/lang/management/ThreadMXBean/LockedMonitorInNative.java
! test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java
+ test/jdk/java/lang/management/ThreadMXBean/libLockedMonitorInNative.c
! test/jdk/jdk/internal/misc/ThreadFlock/ThreadFlockTest.java
+ test/lib/jdk/test/lib/thread/VThreadScheduler.java

Changeset: 9d879186
Branch: premain
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-07-25 07:47:45 +0000
URL:       https://git.openjdk.org/leyden/commit/9d8791864ec48f3321707d7f7805cd3618fc3b51

8335191: RISC-V: verify perf of chacha20

Reviewed-by: fyang

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

Changeset: 8081f870
Branch: premain
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
Date:      2024-07-25 09:16:32 +0000
URL:       https://git.openjdk.org/leyden/commit/8081f8702a89c4895302377be62da22fc34f2c74

8334342: Add MergeStore JMH benchmarks

Reviewed-by: epeter, thartmann

+ test/micro/org/openjdk/bench/vm/compiler/MergeStoreBench.java

Changeset: 3baff2af
Branch: premain
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2024-07-25 09:26:11 +0000
URL:       https://git.openjdk.org/leyden/commit/3baff2af6a30cc6cb2e0d4391db1cf7e61c33f64

8335393: C2: assert(!had_error) failed: bad dominance

Reviewed-by: thartmann, chagedorn

! src/hotspot/share/opto/loopTransform.cpp
+ test/hotspot/jtreg/compiler/rangechecks/TestEmptyLoopDeadCast.java

Changeset: 00b53481
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-07-25 13:16:31 +0000
URL:       https://git.openjdk.org/leyden/commit/00b53481064ed1ca914008d06ce5b530ca7ffe16

8337192: [BACKOUT] JDK-8336098 G1: Refactor G1RebuildRSAndScrubTask

Reviewed-by: tschatzl

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

Changeset: 34ee06f5
Branch: premain
Author:    Vicente Romero <vromero at openjdk.org>
Date:      2024-07-25 13:41:32 +0000
URL:       https://git.openjdk.org/leyden/commit/34ee06f51122e8afb875cc3b75f513912272fd9b

8332850: javac crashes if container for repeatable annotation is not found

Reviewed-by: darcy

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java
+ test/langtools/tools/javac/annotations/repeatingAnnotations/CompletionErrorOnRepeatingAnnosTest.java

Changeset: f61a5059
Branch: premain
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2024-07-25 15:45:41 +0000
URL:       https://git.openjdk.org/leyden/commit/f61a50598958e928e9a4d81130b077cd6eaf876a

8334647: C2: CastII added by PhaseIdealLoop::add_template_assertion_predicate() should have control

Reviewed-by: chagedorn, kvn

! src/hotspot/share/opto/castnode.hpp
! src/hotspot/share/opto/loopPredicate.cpp
! src/hotspot/share/opto/loopTransform.cpp
! src/hotspot/share/opto/loopopts.cpp
! src/hotspot/share/opto/vectorIntrinsics.cpp

Changeset: e74edbae
Branch: premain
Author:    Xiaolong Peng <xpeng at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-07-25 16:04:58 +0000
URL:       https://git.openjdk.org/leyden/commit/e74edbaea9f09169f597a470f647f3b7d10cc71b

8336640: Shenandoah: Parallel worker use in parallel_heap_region_iterate

Reviewed-by: shade, wkemper, ysr

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

Changeset: 81ed0287
Branch: premain
Author:    Jorn Vernee <jvernee at openjdk.org>
Date:      2024-07-25 16:36:31 +0000
URL:       https://git.openjdk.org/leyden/commit/81ed0287175617e6f7ad79dd7036b2fbde27e80a

8337060: Test java/foreign/TestConcurrentClose.java failed: IllegalStateException: SegmentAccessor::doAccess method not being compiled

Reviewed-by: mcimadamore, alanb

! test/jdk/java/foreign/TestConcurrentClose.java

Changeset: cf0d9e0e
Branch: premain
Author:    Vicente Romero <vromero at openjdk.org>
Date:      2024-07-25 17:03:45 +0000
URL:       https://git.openjdk.org/leyden/commit/cf0d9e0e521b495a96a3de7775b1b3ae14d20d80

8337037: compiler internal options are not printing the stacktrace after a compiler crash

Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java
+ src/jdk.compiler/share/classes/com/sun/tools/javac/util/CompilerInternalException.java
! src/jdk.jshell/share/classes/jdk/jshell/TreeDissector.java

Changeset: b5b5a5b8
Branch: premain
Author:    Weijun Wang <weijun at openjdk.org>
Date:      2024-07-25 17:11:59 +0000
URL:       https://git.openjdk.org/leyden/commit/b5b5a5b8e54ebd766456d2a4781a806ff97816a8

8336667: IAE in DerInputStream.toByteArray

Reviewed-by: valeriep

! src/java.base/share/classes/sun/security/util/DerInputStream.java
+ test/jdk/sun/security/util/DerInputBuffer/B8336667/PoC.java
+ test/jdk/sun/security/util/DerInputBuffer/B8336667/Reproducer.java

Changeset: 8c28f25e
Branch: premain
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-07-25 20:59:48 +0000
URL:       https://git.openjdk.org/leyden/commit/8c28f25e1383f10a78b05e47ccf1cc4262069e69

8337124: (fs) sun.nio.fs.WindowsSecurity.enablePrivilege should pin when continuations supported

Reviewed-by: jpai, alanb

! src/java.base/windows/classes/sun/nio/fs/WindowsSecurity.java

Changeset: 0584af23
Branch: premain
Author:    William Kemper <wkemper at openjdk.org>
Date:      2024-07-25 23:59:56 +0000
URL:       https://git.openjdk.org/leyden/commit/0584af23255b6b8f49190eaf2618f3bcc299adfe

8336685: Shenandoah: Remove experimental incremental update mode

Reviewed-by: shade

! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp
! src/hotspot/cpu/ppc/gc/shenandoah/c1/shenandoahBarrierSetC1_ppc.cpp
! src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
! src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.hpp
! src/hotspot/cpu/riscv/gc/shenandoah/c1/shenandoahBarrierSetC1_riscv.cpp
! src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp
! src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.hpp
! src/hotspot/cpu/x86/gc/shenandoah/c1/shenandoahBarrierSetC1_x86.cpp
! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.hpp
! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp
! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.hpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.hpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp
- src/hotspot/share/gc/shenandoah/mode/shenandoahIUMode.cpp
- src/hotspot/share/gc/shenandoah/mode/shenandoahIUMode.hpp
! src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp
! src/hotspot/share/gc/shenandoah/mode/shenandoahSATBMode.cpp
! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp
! src/hotspot/share/opto/classes.hpp
! test/hotspot/jtreg/compiler/c2/aarch64/TestVolatiles.java
! test/hotspot/jtreg/compiler/c2/aarch64/TestVolatilesShenandoah.java
! test/hotspot/jtreg/gc/TestAllocHumongousFragment.java
! test/hotspot/jtreg/gc/shenandoah/TestAllocIntArrays.java
! test/hotspot/jtreg/gc/shenandoah/TestAllocObjectArrays.java
! test/hotspot/jtreg/gc/shenandoah/TestAllocObjects.java
! test/hotspot/jtreg/gc/shenandoah/TestDynamicSoftMaxHeapSize.java
! test/hotspot/jtreg/gc/shenandoah/TestGCThreadGroups.java
! test/hotspot/jtreg/gc/shenandoah/TestHeapUncommit.java
! test/hotspot/jtreg/gc/shenandoah/TestJcmdHeapDump.java
! test/hotspot/jtreg/gc/shenandoah/TestLotsOfCycles.java
! test/hotspot/jtreg/gc/shenandoah/TestObjItrWithHeapDump.java
! test/hotspot/jtreg/gc/shenandoah/TestPeriodicGC.java
! test/hotspot/jtreg/gc/shenandoah/TestReferenceRefersToShenandoah.java
! test/hotspot/jtreg/gc/shenandoah/TestReferenceShortcutCycle.java
! test/hotspot/jtreg/gc/shenandoah/TestRefprocSanity.java
! test/hotspot/jtreg/gc/shenandoah/TestRegionSampling.java
! test/hotspot/jtreg/gc/shenandoah/TestResizeTLAB.java
! test/hotspot/jtreg/gc/shenandoah/TestRetainObjects.java
! test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java
! test/hotspot/jtreg/gc/shenandoah/TestStringDedup.java
! test/hotspot/jtreg/gc/shenandoah/TestStringDedupStress.java
! test/hotspot/jtreg/gc/shenandoah/TestStringInternCleanup.java
! test/hotspot/jtreg/gc/shenandoah/TestVerifyJCStress.java
! test/hotspot/jtreg/gc/shenandoah/TestWrongArrayMember.java
! test/hotspot/jtreg/gc/shenandoah/compiler/BarrierInInfiniteLoop.java
- test/hotspot/jtreg/gc/shenandoah/compiler/TestUnexpectedIUBarrierEA.java
! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java
! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestPauseNotifications.java
! test/hotspot/jtreg/gc/shenandoah/oom/TestClassLoaderLeak.java
! test/hotspot/jtreg/gc/shenandoah/options/TestExplicitGC.java
! test/hotspot/jtreg/gc/shenandoah/options/TestModeUnlock.java
! test/hotspot/jtreg/gc/shenandoah/options/TestSelectiveBarrierFlags.java
! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierDisable.java
! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierEnable.java
! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithShenandoah.java
! test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithShenandoah.java
! test/hotspot/jtreg/gc/stress/systemgc/TestSystemGCWithShenandoah.java

Changeset: ee839b7f
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-26 03:44:22 +0000
URL:       https://git.openjdk.org/leyden/commit/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae

8337239: Fix simple -Wzero-as-null-pointer-constant warnings in classfile code

Reviewed-by: dholmes

! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/defaultMethods.cpp
! src/hotspot/share/classfile/javaAssertions.cpp
! src/hotspot/share/classfile/symbolTable.cpp

Changeset: 29f0f174
Branch: premain
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Date:      2024-07-26 06:23:47 +0000
URL:       https://git.openjdk.org/leyden/commit/29f0f174a0460a98c5500c4cf4bf9abdf9354572

8336879: Always true condition 'img != null' in GTKPainter.paintPopupMenuBackground

Reviewed-by: psadhukhan, tr

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

Changeset: 487450cb
Branch: premain
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Date:      2024-07-26 06:26:52 +0000
URL:       https://git.openjdk.org/leyden/commit/487450cb5e8b3781f77896125573ee89a556b454

8216471: GTK LnF: Frame is clipped and does not show JTable,Tooltip and JTree demo in SwingSet2 demo

Reviewed-by: psadhukhan, achung

! src/demo/share/jfc/SwingSet2/SwingSet2.java

Changeset: 7f119354
Branch: premain
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-07-26 07:08:33 +0000
URL:       https://git.openjdk.org/leyden/commit/7f11935461a6ff1ef0fac800fb4264a519e21061

8337167: StringSize deduplication

Reviewed-by: liach, rriggs

! src/java.base/share/classes/java/lang/AbstractStringBuilder.java
! src/java.base/share/classes/java/lang/Integer.java
! src/java.base/share/classes/java/lang/Long.java
! src/java.base/share/classes/java/lang/StringConcatHelper.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/share/classes/jdk/internal/util/DecimalDigits.java

Changeset: d10afa26
Branch: premain
Author:    Fei Gao <fgao at openjdk.org>
Date:      2024-07-26 09:36:23 +0000
URL:       https://git.openjdk.org/leyden/commit/d10afa26e5c59475e49b353ed34e8e85d0615d92

8336245: AArch64: remove extra register copy when converting from long to pointer

Co-authored-by: Andrew Haley <aph at openjdk.org>
Reviewed-by: aph, adinn

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/gc/x/x_aarch64.ad
! src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad
! src/hotspot/share/opto/machnode.cpp
+ test/hotspot/jtreg/compiler/c2/TestCastX2P.java

Changeset: 2aeb12ec
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-07-26 11:20:40 +0000
URL:       https://git.openjdk.org/leyden/commit/2aeb12ec03944c777d617d0be48982fd225b16e7

8334482: Shenandoah: Deadlock when safepoint is pending during nmethods iteration

Reviewed-by: wkemper, xpeng, rkennke

! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp
! src/hotspot/share/gc/shenandoah/shenandoahNMethod.hpp

Changeset: 374fca0f
Branch: premain
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-07-26 11:22:32 +0000
URL:       https://git.openjdk.org/leyden/commit/374fca0fcbc049f937fa49bb4825edcbbf961f2b

8335967: "text-decoration: none" does not work with "A" HTML tags

Reviewed-by: abhiscxk, dmarkov, honkar, prr

! src/java.desktop/share/classes/javax/swing/text/html/CSS.java
+ test/jdk/javax/swing/text/html/HTMLDocument/HTMLTextDecorationNone.java

Changeset: 5ff7c57f
Branch: premain
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Date:      2024-07-26 12:10:21 +0000
URL:       https://git.openjdk.org/leyden/commit/5ff7c57f9ff5428ef3d2aedd7e860bb1e8ff29ea

8337168: Optimize LocalDateTime.toString

Reviewed-by: liach, naoto

! src/java.base/share/classes/java/time/LocalDate.java
! src/java.base/share/classes/java/time/LocalDateTime.java
! src/java.base/share/classes/java/time/LocalTime.java

Changeset: 3abe8a6e
Branch: premain
Author:    Tomas Zezula <tzezula at openjdk.org>
Date:      2024-07-26 14:42:24 +0000
URL:       https://git.openjdk.org/leyden/commit/3abe8a6e5e459fb764b8cef2425be50fe1a83fab

8336663: [JVMCI] VM Crash on ZGC due to incompatible handle returned by HotSpotJVMCIRuntime#getJObjectValue

Reviewed-by: dnsimon, never

! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/CompilerToVM.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java

Changeset: 4bcb8f04
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-26 15:45:12 +0000
URL:       https://git.openjdk.org/leyden/commit/4bcb8f04ed3623da7c84dda28017f473cbc97e53

8337243: Fix more -Wzero-as-null-pointer-constant warnings in compiler code

Reviewed-by: vlivanov, kvn

! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/ci/ciConstantPoolCache.cpp
! src/hotspot/share/ci/ciStreams.cpp
! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/dependencies.cpp
! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/code/oopRecorder.cpp

Changeset: f35af717
Branch: premain
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-07-26 15:55:12 +0000
URL:       https://git.openjdk.org/leyden/commit/f35af7171213c09107b99104a73022853bff91b0

8334315: Shenandoah: reduce GC logging noise

Reviewed-by: wkemper, ysr, shade

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

Changeset: 4f194f10
Branch: premain
Author:    William Kemper <wkemper at openjdk.org>
Date:      2024-07-26 15:57:58 +0000
URL:       https://git.openjdk.org/leyden/commit/4f194f10a1481cdc9df4e6338f6cabd07a34c84c

8337241: Shenandoah: Normalize include guards

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahController.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp

Changeset: 0c3720b4
Branch: premain
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Date:      2024-07-26 17:39:00 +0000
URL:       https://git.openjdk.org/leyden/commit/0c3720b42176c7bc92105be87df7449973fbcea0

8335131: Test "javax/swing/JColorChooser/Test6977726.java" failed on ubuntu x64 because "Preview" title is missing for GTK L&F

Reviewed-by: dnguyen, psadhukhan

! test/jdk/javax/swing/JColorChooser/Test6977726.java

Changeset: abc4ca5a
Branch: premain
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2024-07-26 17:55:35 +0000
URL:       https://git.openjdk.org/leyden/commit/abc4ca5a8c440f8f3f36a9b35036772c5b5ee7ea

8330427: Obsolete -XX:+PreserveAllAnnotations

Reviewed-by: dholmes, sspitsyn, coleenp

! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/classFileParser.hpp
! src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp
! src/hotspot/share/prims/jvmtiClassFileReconstituter.hpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/globals.hpp
- test/jdk/java/lang/instrument/RetransformRecordAnnotation.java

Changeset: 034297a6
Branch: premain
Author:    Fernando Guallini <fguallini at openjdk.org>
Committer: Bradford Wetmore <wetmore at openjdk.org>
Date:      2024-07-26 18:51:12 +0000
URL:       https://git.openjdk.org/leyden/commit/034297a6bd9bfcea7fa48792f54c84a6e976b319

8336240: Test com/sun/crypto/provider/Cipher/DES/PerformanceTest.java fails with java.lang.ArithmeticException

Reviewed-by: wetmore

! test/jdk/ProblemList.txt
! test/jdk/TEST.groups
! test/jdk/com/sun/crypto/provider/Cipher/DES/PerformanceTest.java

Changeset: 2fbdbaca
Branch: premain
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Claes Redestad <redestad at openjdk.org>
Date:      2024-07-27 22:54:47 +0000
URL:       https://git.openjdk.org/leyden/commit/2fbdbacad7ad45055a482c764f84da4568383020

8337245: Fix wrong comment of StringConcatHelper

Reviewed-by: phh, redestad

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

Changeset: 90641a60
Branch: premain
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2024-07-29 05:05:32 +0000
URL:       https://git.openjdk.org/leyden/commit/90641a601c9385b5e76e1abc5362ace3ab1fff3d

8336095: Use-after-free in Superword leads to memory corruption

Reviewed-by: epeter, kvn, rrich

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

Changeset: 657c0bdd
Branch: premain
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2024-07-29 05:31:10 +0000
URL:       https://git.openjdk.org/leyden/commit/657c0bddf90b537ac653817571532705a6e3643a

8336999: Verification for resource area allocated data structures in C2

Reviewed-by: chagedorn, kvn

! src/hotspot/share/ci/ciReplay.cpp
! src/hotspot/share/libadt/vectset.cpp
! src/hotspot/share/libadt/vectset.hpp
! src/hotspot/share/memory/allocation.cpp
! src/hotspot/share/memory/allocation.hpp
! src/hotspot/share/opto/block.cpp
! src/hotspot/share/opto/block.hpp
! src/hotspot/share/opto/domgraph.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/loopnode.hpp
! src/hotspot/share/opto/node.cpp
! src/hotspot/share/opto/node.hpp
! src/hotspot/share/opto/phaseX.cpp
! src/hotspot/share/opto/vector.cpp

Changeset: dab2a0b5
Branch: premain
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2024-07-29 09:10:25 +0000
URL:       https://git.openjdk.org/leyden/commit/dab2a0b5978cdd3fad693e4c120a84bb64a3ccde

8337222: gc/TestDisableExplicitGC.java fails due to unexpected CodeCache GC

Reviewed-by: iwalulya, shade

! test/hotspot/jtreg/gc/TestDisableExplicitGC.java

Changeset: db168d9e
Branch: premain
Author:    Jan Kratochvil <jkratochvil at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
Date:      2024-07-29 09:18:56 +0000
URL:       https://git.openjdk.org/leyden/commit/db168d9e10c4a302b743ee208e24ba7303fec582

8336966: Alpine Linux x86_64 compilation error: sendfile64

Reviewed-by: bpb

! src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c
! src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c

Changeset: 9124a94e
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-07-29 09:52:38 +0000
URL:       https://git.openjdk.org/leyden/commit/9124a94e383f5bc6a3376eecc97ee8bd22f9e420

8337165: Test jdk/jfr/event/gc/stacktrace/TestG1YoungAllocationPendingStackTrace.java failed: IndexOutOfBoundsException: Index 64 out of bounds for length 64

Reviewed-by: phh

! test/jdk/jdk/jfr/event/gc/stacktrace/TestDefNewAllocationPendingStackTrace.java
! test/jdk/jdk/jfr/event/gc/stacktrace/TestG1HumongousAllocationPendingStackTrace.java
! test/jdk/jdk/jfr/event/gc/stacktrace/TestG1OldAllocationPendingStackTrace.java
! test/jdk/jdk/jfr/event/gc/stacktrace/TestG1YoungAllocationPendingStackTrace.java
! test/jdk/jdk/jfr/event/gc/stacktrace/TestMarkSweepCompactAllocationPendingStackTrace.java
! test/jdk/jdk/jfr/event/gc/stacktrace/TestMetaspaceG1GCAllocationPendingStackTrace.java
! test/jdk/jdk/jfr/event/gc/stacktrace/TestMetaspaceParallelGCAllocationPendingStackTrace.java
! test/jdk/jdk/jfr/event/gc/stacktrace/TestMetaspaceSerialGCAllocationPendingStackTrace.java
! test/jdk/jdk/jfr/event/gc/stacktrace/TestParallelMarkSweepAllocationPendingStackTrace.java
! test/jdk/jdk/jfr/event/gc/stacktrace/TestParallelScavengeAllocationPendingStackTrace.java

Changeset: cd52ad80
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-07-29 12:30:57 +0000
URL:       https://git.openjdk.org/leyden/commit/cd52ad80a82c8165424722dcddd37d6584137031

8337267: [REDO] G1: Refactor G1RebuildRSAndScrubTask

Reviewed-by: gli, tschatzl

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

Changeset: ee365d75
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-07-29 13:37:56 +0000
URL:       https://git.openjdk.org/leyden/commit/ee365d75cca6f33e5781fe514e557caba2b67c32

8336342: Fix known X11 library locations in sysroot

Reviewed-by: jwaters, phh, prr

! make/autoconf/lib-x11.m4

Changeset: c23d37e1
Branch: premain
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-07-29 16:43:25 +0000
URL:       https://git.openjdk.org/leyden/commit/c23d37e10a429c0e7248593b07ef1ccdcd34bd1c

8337300: java/lang/Process/WaitForDuration.java leaves child process behind

Reviewed-by: alanb, iris, bpb

! test/jdk/java/lang/Process/WaitForDuration.java

Changeset: c4e6255a
Branch: premain
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-07-29 16:55:38 +0000
URL:       https://git.openjdk.org/leyden/commit/c4e6255ac3ec5520c4cb6d0d4ad9013da177ba88

8332738: Debug agent can deadlock on callbackLock when using StackFrame.PopFrames

Reviewed-by: sspitsyn, amenkov

! src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c
! src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.h
! src/jdk.jdwp.agent/share/native/libjdwp/invoker.c
! src/jdk.jdwp.agent/share/native/libjdwp/stepControl.c
! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c

Changeset: a86244f8
Branch: premain
Author:    Archie Cobbs <acobbs at openjdk.org>
Date:      2024-07-29 19:16:39 +0000
URL:       https://git.openjdk.org/leyden/commit/a86244f83cc4e234bdf8dc2c8d87640b6aab8463

6381729: Javadoc for generic constructor doesn't document type parameter

Reviewed-by: jjg, liach

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java
! test/langtools/jdk/javadoc/doclet/testErasure/TestErasure.java
! test/langtools/jdk/javadoc/doclet/testTypeParams/TestTypeParameters.java
= test/langtools/jdk/javadoc/doclet/testTypeParams/pkg/CtorTypeParam.java

Changeset: bd36b6ae
Branch: premain
Author:    Justin Lu <jlu at openjdk.org>
Date:      2024-07-29 19:28:14 +0000
URL:       https://git.openjdk.org/leyden/commit/bd36b6ae5d0d760670a0bd722878614a6cd553d6

8337285: Examine java.text.DecimalFormat API for api/implXxx tag usage

Reviewed-by: naoto, liach

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

Changeset: ab27090a
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-29 21:58:08 +0000
URL:       https://git.openjdk.org/leyden/commit/ab27090aa085283233851410827767785b3b7b1f

8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/CodeModel.java
! src/java.base/share/classes/java/lang/classfile/attribute/CodeAttribute.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractUnboundModel.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedFieldBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/TerminalCodeBuilder.java
! test/jdk/jdk/classfile/BuilderBlockTest.java
! test/jdk/jdk/classfile/CorpusTest.java
! test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java
! test/jdk/jdk/classfile/StackMapsTest.java

Changeset: 7e21d4c1
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-07-30 03:03:43 +0000
URL:       https://git.openjdk.org/leyden/commit/7e21d4c1916d6690b717911179314c26a0da5ed9

8337268: Redundant Math.ceil in StyleSheet.ListPainter#drawShape

Reviewed-by: prr, aivanov

! src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java

Changeset: bc7c255b
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-30 07:24:22 +0000
URL:       https://git.openjdk.org/leyden/commit/bc7c255b156bf3bb3fd8c3f622b8127ab27e7c7a

8337416: Fix -Wzero-as-null-pointer-constant warnings in misc. runtime code

Reviewed-by: dholmes, jwaters

! src/hotspot/share/logging/logConfiguration.cpp
! src/hotspot/share/memory/metaspace/metachunk.cpp
! src/hotspot/share/memory/metaspace/rootChunkArea.cpp
! src/hotspot/share/memory/virtualspace.cpp
! src/hotspot/share/oops/constantPool.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/vframeArray.cpp

Changeset: 9e6e0a8f
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-07-30 08:27:27 +0000
URL:       https://git.openjdk.org/leyden/commit/9e6e0a8f341389215f0db6b2260f2b16351f02be

8336343: Add more known sysroot library locations for ALSA

Reviewed-by: phh, prr, ihse

! make/autoconf/lib-alsa.m4

Changeset: 156f0b43
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-07-30 08:29:23 +0000
URL:       https://git.openjdk.org/leyden/commit/156f0b4332bf076165898417cf6678d2fc32df5c

8337213: Shenandoah: Add verification for class mirrors

Reviewed-by: rkennke, wkemper

! src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp

Changeset: 7ac53118
Branch: premain
Author:    Amit Kumar <amitkumar at openjdk.org>
Date:      2024-07-30 09:32:27 +0000
URL:       https://git.openjdk.org/leyden/commit/7ac531181c25815577ba2f6f426e1da270e4f589

8331126: [s390x] secondary_super_cache does not scale well

Reviewed-by: lucy, aph, mdoerr

! src/hotspot/cpu/s390/macroAssembler_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.hpp
! src/hotspot/cpu/s390/s390.ad
! src/hotspot/cpu/s390/stubGenerator_s390.cpp
! src/hotspot/cpu/s390/vm_version_s390.cpp
! src/hotspot/cpu/s390/vm_version_s390.hpp

Changeset: 0325ab8d
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-07-30 10:44:31 +0000
URL:       https://git.openjdk.org/leyden/commit/0325ab8d2353f29ac40ff4b028cbc29bff40c59b

8335610: DiagnosticFramework: CmdLine::is_executable() correction

Reviewed-by: dholmes, jsjolen

! src/hotspot/share/services/diagnosticFramework.hpp

Changeset: 81628328
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-07-30 12:40:35 +0000
URL:       https://git.openjdk.org/leyden/commit/8162832832ac6e8c17f942e718e309a3489e0da6

8333354: ubsan: frame.inline.hpp:91:25: and src/hotspot/share/runtime/frame.inline.hpp:88:29: runtime error: member call on null pointer of type 'const struct SmallRegisterMap'

Co-authored-by: Kim Barrett <kbarrett at openjdk.org>
Reviewed-by: rrich, clanger

! src/hotspot/cpu/aarch64/smallRegisterMap_aarch64.inline.hpp
! src/hotspot/cpu/arm/smallRegisterMap_arm.inline.hpp
! src/hotspot/cpu/ppc/smallRegisterMap_ppc.inline.hpp
! src/hotspot/cpu/riscv/smallRegisterMap_riscv.inline.hpp
! src/hotspot/cpu/s390/smallRegisterMap_s390.inline.hpp
! src/hotspot/cpu/x86/smallRegisterMap_x86.inline.hpp
! src/hotspot/cpu/zero/smallRegisterMap_zero.inline.hpp
! src/hotspot/share/oops/stackChunkOop.cpp
! src/hotspot/share/oops/stackChunkOop.inline.hpp
! src/hotspot/share/runtime/continuationFreezeThaw.cpp

Changeset: 79bdd811
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-07-30 13:38:11 +0000
URL:       https://git.openjdk.org/leyden/commit/79bdd811876d75974536aac088bae1719387c97f

8336763: Parallel: Merge PCMarkAndPushClosure and PCIterateMarkAndPushClosure

Reviewed-by: gli, zgu

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

Changeset: 41486131
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-07-30 13:47:58 +0000
URL:       https://git.openjdk.org/leyden/commit/41486131481164a559aa534807fe1a77a7d29fc8

8335907: JFR: Make SettingControls more robust

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java
+ src/jdk.jfr/share/classes/jdk/jfr/internal/settings/BooleanSetting.java
- src/jdk.jfr/share/classes/jdk/jfr/internal/settings/BooleanValue.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/CutoffSetting.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/EnabledSetting.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/LevelSetting.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/PeriodSetting.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/StackTraceSetting.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThresholdSetting.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottleSetting.java
- src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottleUnit.java
+ src/jdk.jfr/share/classes/jdk/jfr/internal/util/Rate.java
+ src/jdk.jfr/share/classes/jdk/jfr/internal/util/TimespanUnit.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/util/Utils.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueFormatter.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueParser.java
+ test/jdk/jdk/jfr/api/settings/TestSettingControl.java

Changeset: 1cb27f7e
Branch: premain
Author:    Neethu Prasad <nprasad at openjdk.org>
Date:      2024-07-30 14:08:17 +0000
URL:       https://git.openjdk.org/leyden/commit/1cb27f7e2355ccb911bb274fc004e5bc57fd5dc9

8334230: Optimize C2 classes layout

Reviewed-by: shade, kvn, thartmann

! src/hotspot/share/gc/shared/c2/barrierSetC2.hpp
! src/hotspot/share/libadt/vectset.hpp
! src/hotspot/share/opto/callnode.hpp
! src/hotspot/share/opto/memnode.cpp

Changeset: 2c9fd901
Branch: premain
Author:    Vanitha B P <Vanitha.b.p at oracle.com>
Committer: Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2024-07-30 15:04:57 +0000
URL:       https://git.openjdk.org/leyden/commit/2c9fd9016f4675448a62380ff2b86533020e690f

8336315: tools/jpackage/windows/WinChildProcessTest.java Failed: Check is calculator process is alive

Reviewed-by: asemenyuk, almatvee

! test/jdk/tools/jpackage/apps/ChildProcessAppLauncher.java
! test/jdk/tools/jpackage/windows/WinChildProcessTest.java

Changeset: a91f9ba8
Branch: premain
Author:    Gerard Ziemski <gziemski at openjdk.org>
Date:      2024-07-30 15:22:25 +0000
URL:       https://git.openjdk.org/leyden/commit/a91f9ba84906dae10b050e15307ba0f0f05af3e4

8301403: Eliminate memory allocations in JVMFlag::printFlags during signal handling

Reviewed-by: stuefe, jsjolen, dholmes

! src/hotspot/share/runtime/flags/jvmFlag.cpp
! src/hotspot/share/utilities/bitMap.cpp
! src/hotspot/share/utilities/bitMap.hpp
! src/hotspot/share/utilities/globalDefinitions.hpp

Changeset: 6154a212
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-30 17:41:38 +0000
URL:       https://git.openjdk.org/leyden/commit/6154a2129ba505b7163a1998792296827a056750

8336032: Enforce immutability of Lists used by ClassFile API

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/AttributedElement.java
! src/java.base/share/classes/java/lang/classfile/ClassSignature.java
! src/java.base/share/classes/java/lang/classfile/CompoundElement.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractUnboundModel.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedFieldBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/UnboundAttribute.java
! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java

Changeset: 93c19ac7
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-30 17:41:49 +0000
URL:       https://git.openjdk.org/leyden/commit/93c19ac73c2feb8d6191bc5da98b4a9c8e2b5590

8337219: AccessFlags factories do not require necessary arguments

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/AccessFlags.java
! src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
! src/java.base/share/classes/java/lang/classfile/FieldBuilder.java
! src/java.base/share/classes/java/lang/classfile/MethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedFieldBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/FieldImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/MethodImpl.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java
! test/jdk/jdk/classfile/AccessFlagsTest.java
! test/jdk/jdk/classfile/BuilderBlockTest.java
! test/jdk/jdk/classfile/BuilderTryCatchTest.java
! test/jdk/jdk/classfile/LDCTest.java
! test/jdk/jdk/classfile/LowAdaptTest.java
! test/jdk/jdk/classfile/LvtTest.java
! test/jdk/jdk/classfile/OneToOneTest.java
! test/jdk/jdk/classfile/SwapTest.java
! test/jdk/jdk/classfile/WriteTest.java
! test/jdk/jdk/classfile/examples/ExampleGallery.java
! test/micro/org/openjdk/bench/jdk/classfile/Write.java

Changeset: f5c9e8f1
Branch: premain
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
Date:      2024-07-30 18:40:37 +0000
URL:       https://git.openjdk.org/leyden/commit/f5c9e8f1229f3aa00743119a2dee3e15d57048d8

8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID

Reviewed-by: kevinw, stuefe, lmesnik

! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/codeCache.hpp
! src/hotspot/share/prims/wbtestmethods/parserTests.cpp
! src/hotspot/share/services/diagnosticArgument.cpp
! src/hotspot/share/services/diagnosticArgument.hpp
! src/hotspot/share/services/diagnosticCommand.cpp
! test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDumpBase.java
! test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestStaticDump.java
! test/hotspot/jtreg/serviceability/ParserTest.java
+ test/jdk/sun/tools/jcmd/TestJcmdPIDSubstitution.java
! test/lib/jdk/test/whitebox/parser/DiagnosticCommand.java

Changeset: 6c3ba5a6
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-30 21:19:50 +0000
URL:       https://git.openjdk.org/leyden/commit/6c3ba5a6c47d29908ddaf58582ee8d26bb8779f9

8337415: Remove inappropriate Atomic access in FreeListAllocator

Reviewed-by: tschatzl, shade

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

Changeset: d39e7af2
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-07-30 22:35:14 +0000
URL:       https://git.openjdk.org/leyden/commit/d39e7af2e5d28df43c0b2dad770f41adede5cc29

8320561: Inconsistency in monitorinflation logging

Reviewed-by: stefank, shade

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

Changeset: 5b7bb40d
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-07-30 22:35:28 +0000
URL:       https://git.openjdk.org/leyden/commit/5b7bb40d1f5a8e1261cc252db2a09b5e4f07e5f0

8325002: Exceptions::fthrow needs to ensure it truncates to a valid utf8 string

Reviewed-by: djelinski, stuefe

! src/hotspot/share/utilities/exceptions.cpp
! src/hotspot/share/utilities/utf8.cpp
! src/hotspot/share/utilities/utf8.hpp
! test/hotspot/gtest/utilities/test_utf8.cpp

Changeset: 1c6fef8f
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-07-31 00:58:52 +0000
URL:       https://git.openjdk.org/leyden/commit/1c6fef8f1cd12b26de9d31799a6516ce4399313f

8337515: JVM_DumpAllStacks is dead code

Reviewed-by: kvn

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

Changeset: e63d0165
Branch: premain
Author:    Ashutosh Mehra <asmehra at openjdk.org>
Date:      2024-07-31 01:36:37 +0000
URL:       https://git.openjdk.org/leyden/commit/e63d01654e0b702b3a8c0c4de97a6bb6893fbd1f

8337031: Improvements to CompilationMemoryStatistic

Reviewed-by: kvn, stuefe

! src/hotspot/share/compiler/compilationMemoryStatistic.cpp
! src/hotspot/share/compiler/compilationMemoryStatistic.hpp
! src/hotspot/share/memory/arena.cpp
! src/hotspot/share/memory/arena.hpp
! test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java
! test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerMemoryStatisticTest.java

Changeset: de0b5040
Branch: premain
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2024-07-31 08:08:15 +0000
URL:       https://git.openjdk.org/leyden/commit/de0b50400a4155554c83d5c3346ab1ec5353df61

8336912: G1: Undefined behavior for G1ConfidencePercent=0

Reviewed-by: ayang, sangheki

! src/hotspot/share/gc/g1/g1_globals.hpp
! test/hotspot/jtreg/gc/arguments/TestG1PercentageOptions.java

Changeset: 9b428dda
Branch: premain
Author:    David Leopoldseder <davleopo at openjdk.org>
Committer: Doug Simon <dnsimon at openjdk.org>
Date:      2024-07-31 09:40:47 +0000
URL:       https://git.openjdk.org/leyden/commit/9b428dda8fb86ed595b05f3c930b3ce9c341db9b

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

Reviewed-by: dnsimon, never

! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/SimpleDebugInfoTest.java

Changeset: c73b3cb5
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-07-31 12:56:43 +0000
URL:       https://git.openjdk.org/leyden/commit/c73b3cb5996723c5a15c833a9da059b79c99cf9c

8336635: Add IR test for Reference.refersTo intrinsic

Reviewed-by: thartmann, kvn

+ test/hotspot/jtreg/compiler/c2/irTests/gc/ReferenceRefersToTests.java

Changeset: 07dd7250
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-31 13:15:52 +0000
URL:       https://git.openjdk.org/leyden/commit/07dd725025a54035436a76ac4c0a8bb2b12e264a

8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code

Reviewed-by: dholmes, shade, jwaters, sspitsyn

! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/jvmtiExport.cpp
! src/hotspot/share/prims/jvmtiTrace.cpp
! src/hotspot/share/prims/methodHandles.cpp
! src/hotspot/share/prims/perf.cpp
! src/hotspot/share/prims/unsafe.cpp

Changeset: 61386c19
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-31 13:17:30 +0000
URL:       https://git.openjdk.org/leyden/commit/61386c199a3b29457c002ad31a23990b7f6f88fd

8337523: Fix -Wzero-as-null-pointer-constant warnings in jvmci code

Reviewed-by: chagedorn, shade

! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp

Changeset: 7121d71b
Branch: premain
Author:    Gui Cao <gcao at openjdk.org>
Date:      2024-07-31 14:43:35 +0000
URL:       https://git.openjdk.org/leyden/commit/7121d71b516b415c7c11e3643731cd32d4057aa6

8337421: RISC-V: client VM build failure after JDK-8335191

Reviewed-by: fyang, mli

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

Changeset: f2ba2ebb
Branch: premain
Author:    Jasmine Karthikeyan <jkarthikeyan at openjdk.org>
Date:      2024-07-31 15:16:21 +0000
URL:       https://git.openjdk.org/leyden/commit/f2ba2ebbcaba2784b24e7fe94c235ca652f7c9a2

8331090: Run Ideal_minmax before de-canonicalizing CMoves

Reviewed-by: thartmann, epeter

! src/hotspot/share/opto/movenode.cpp
! test/hotspot/jtreg/compiler/c2/irTests/TestIfMinMax.java

Changeset: fdb4350f
Branch: premain
Author:    Daniel Lund?n <dlunden at openjdk.org>
Date:      2024-07-31 16:05:42 +0000
URL:       https://git.openjdk.org/leyden/commit/fdb4350fcecef1915cdbc27ece24153a1b6c884d

8324345: Stack overflow during C2 compilation when splitting memory phi

Reviewed-by: thartmann, kvn

! src/hotspot/share/opto/escape.cpp
! src/hotspot/share/opto/escape.hpp
+ test/hotspot/jtreg/compiler/escapeAnalysis/TestFindInstMemRecursion.java
! test/hotspot/jtreg/compiler/vectorapi/VectorReplicateLongSpecialImmTest.java

Changeset: e4c7850c
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-07-31 16:24:07 +0000
URL:       https://git.openjdk.org/leyden/commit/e4c7850c177899a5da6f5050cb0647a6e1a75d31

8337027: Parallel: Obsolete BaseFootPrintEstimate

Reviewed-by: tschatzl, kbarrett

! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp
! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.hpp
! src/hotspot/share/gc/parallel/psGCAdaptivePolicyCounters.cpp
! src/hotspot/share/gc/parallel/psGCAdaptivePolicyCounters.hpp
! src/hotspot/share/gc/shared/gc_globals.hpp
! src/hotspot/share/runtime/arguments.cpp
! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/resources/aliasmap

Changeset: 8f039b56
Branch: premain
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-07-31 17:55:01 +0000
URL:       https://git.openjdk.org/leyden/commit/8f039b56294604271c8ee896aca49d325b5472e5

8336919: Cleanup and rename tags in placeholders code

Co-authored-by: Frederic Parain <fparain at openjdk.org>
Reviewed-by: iklam, fparain, dholmes

! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/placeholders.cpp
! src/hotspot/share/classfile/placeholders.hpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! test/hotspot/gtest/classfile/test_placeholders.cpp

Changeset: a45bb55d
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-07-31 17:58:52 +0000
URL:       https://git.openjdk.org/leyden/commit/a45bb55ddb6abfa520a2e4d7a5cd4d638a526efd

8337501: JFR: Use TimespanUnit

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/ArgumentParser.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/model/Utilities.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/util/TimespanUnit.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueParser.java

Changeset: 97f7c03d
Branch: premain
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
Date:      2024-07-31 18:05:49 +0000
URL:       https://git.openjdk.org/leyden/commit/97f7c03dd0ff389abefed7ea2a7257bcb42e0754

8336495: Remove unnecessary casts in output.cpp

Reviewed-by: chagedorn, kvn

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

Changeset: 8af2ef35
Branch: premain
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2024-07-31 20:02:25 +0000
URL:       https://git.openjdk.org/leyden/commit/8af2ef35b6f9399b6d25ff7a4a72ad283df63f03

8331015: Obsolete -XX:+UseNotificationThread

Reviewed-by: dholmes, kevinw, sspitsyn, coleenp

! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/serviceThread.cpp
! src/hotspot/share/services/lowMemoryDetector.hpp
! src/hotspot/share/services/management.cpp

Changeset: 65646b5f
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-08-01 03:35:43 +0000
URL:       https://git.openjdk.org/leyden/commit/65646b5f81279a7fcef3ea04ef9894cf66f77a5a

8337457: Redundant Math.round call in AquaProgressBarUI#getStringPlacement

Reviewed-by: azvegint

! src/java.desktop/macosx/classes/com/apple/laf/AquaProgressBarUI.java

Changeset: cf1230a5
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-08-01 07:28:29 +0000
URL:       https://git.openjdk.org/leyden/commit/cf1230a5f7e5ae4c72ec6243fff1d0b0eb27779a

8337546: Remove unused GCCause::_adaptive_size_policy

Reviewed-by: tschatzl, kbarrett

! src/hotspot/share/gc/shared/gcCause.cpp
! src/hotspot/share/gc/shared/gcCause.hpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GCCause.java
! test/jdk/jdk/jfr/event/gc/collection/TestGCCauseWithParallelOld.java

Changeset: 8eb56845
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-08-01 07:28:39 +0000
URL:       https://git.openjdk.org/leyden/commit/8eb56845e46e8e4867915c8c079adfe1196dcbbc

8337550: Add documentation to TestOutOfMemoryDuringInit.java

Reviewed-by: dholmes

! test/hotspot/jtreg/runtime/ClassInitErrors/TestOutOfMemoryDuringInit.java

Changeset: f174bbd3
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-08-01 08:14:17 +0000
URL:       https://git.openjdk.org/leyden/commit/f174bbd3baf351ae9248b70454b3bc5a89acd7c6

8337473: Remove sun/management/jdp tests from ProblemList on Linux-aarch64, MacOSX

Reviewed-by: dcubed

! test/jdk/ProblemList.txt

Changeset: c6f0a35e
Branch: premain
Author:    Matthew Donovan <mdonovan at openjdk.org>
Date:      2024-08-01 11:40:44 +0000
URL:       https://git.openjdk.org/leyden/commit/c6f0a35e9e3eeaab1e238e8712051a626b337e0b

8333317: Test sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java failed with: Invalid ECDH ServerKeyExchange signature

Reviewed-by: rhalade

! test/jdk/ProblemList.txt
! test/jdk/sun/security/pkcs11/PKCS11Test.java
! test/jdk/sun/security/pkcs11/Signature/TestDSAKeyLength.java

Changeset: 022899a7
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-08-01 13:39:49 +0000
URL:       https://git.openjdk.org/leyden/commit/022899a7eb0100bd6d738471f52e5028e3e5f18e

8337641: G1: Remove unused G1CollectedHeap::alloc_highest_free_region

Reviewed-by: tschatzl

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1HeapRegionManager.cpp
! src/hotspot/share/gc/g1/g1HeapRegionManager.hpp

Changeset: 27af80ef
Branch: premain
Author:    Jorn Vernee <jvernee at openjdk.org>
Date:      2024-08-01 14:36:03 +0000
URL:       https://git.openjdk.org/leyden/commit/27af80ef9e676aaf9016279ff0c7990e2cdfe9ed

8324260: java/foreign/TestStubAllocFailure.java run timeout with -Xcomp

Reviewed-by: alanb, jpai, shade

! test/jdk/java/foreign/TestStubAllocFailure.java

Changeset: 9fe6e231
Branch: premain
Author:    Hannes Greule <hgreule at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-08-01 14:41:25 +0000
URL:       https://git.openjdk.org/leyden/commit/9fe6e2316aef8fd125a7905cff2a2d9ae5d26109

8335638: Calling VarHandle.{access-mode} methods reflectively throws wrong exception

Reviewed-by: liach

! src/hotspot/share/prims/methodHandles.cpp
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestReflection.java

Changeset: f1fa64b6
Branch: premain
Author:    Mark Powers <mpowers at openjdk.org>
Date:      2024-08-01 16:37:20 +0000
URL:       https://git.openjdk.org/leyden/commit/f1fa64b6b67f2eef916b8d92eb522ccb19035e12

4966250: SSLSessionContext.setSessionTimeout() documentation could be updated

Reviewed-by: mullan

! src/java.base/share/classes/javax/net/ssl/SSLSessionContext.java

Changeset: 21e86d10
Branch: premain
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-08-01 19:02:33 +0000
URL:       https://git.openjdk.org/leyden/commit/21e86d10a726fe707febb0111f5b80d8d1d29f03

8334405: java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in testWakeupDuringSelect

Reviewed-by: dfuchs, alanb, vtewari

! test/jdk/java/nio/channels/Selector/SelectWithConsumer.java

Changeset: dc35f3e8
Branch: premain
Author:    Sandhya Viswanathan <sviswanathan at openjdk.org>
Date:      2024-08-01 23:02:23 +0000
URL:       https://git.openjdk.org/leyden/commit/dc35f3e8a84c8f622a4cabb8aee0f96de2e2ea30

8337062: x86_64: Unordered add/mul reduction support for vector api

Reviewed-by: jbhateja, sgibbons

! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp
! src/hotspot/cpu/x86/x86.ad
! test/jdk/jdk/incubator/vector/Double128VectorTests.java
! test/jdk/jdk/incubator/vector/Double256VectorTests.java
! test/jdk/jdk/incubator/vector/Double512VectorTests.java
! test/jdk/jdk/incubator/vector/Double64VectorTests.java
! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Float128VectorTests.java
! test/jdk/jdk/incubator/vector/Float256VectorTests.java
! test/jdk/jdk/incubator/vector/Float512VectorTests.java
! test/jdk/jdk/incubator/vector/Float64VectorTests.java
! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java
! test/jdk/jdk/incubator/vector/gen-template.sh
! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-header.template

Changeset: a89b5251
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-08-02 10:51:25 +0000
URL:       https://git.openjdk.org/leyden/commit/a89b525189fbc0559be9edc0de9f4288ca676139

8337721: G1: Remove unused G1CollectedHeap::young_collection_verify_type

Reviewed-by: tschatzl

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

Changeset: 328a0533
Branch: premain
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-08-02 11:47:26 +0000
URL:       https://git.openjdk.org/leyden/commit/328a0533b2ee6793130dfb68d931e0ebd60c6b5d

8335059: Consider renaming ClassLoaderData::keep_alive

Reviewed-by: dholmes, stefank

! src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp
! src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp
! src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp
! src/hotspot/share/classfile/classLoaderData.cpp
! src/hotspot/share/classfile/classLoaderData.hpp
! src/hotspot/share/classfile/classLoaderDataGraph.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/moduleEntry.cpp
! src/hotspot/share/prims/jvm.cpp

Changeset: 066db6eb
Branch: premain
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-08-02 13:06:22 +0000
URL:       https://git.openjdk.org/leyden/commit/066db6eb21e9c9202857f9f6adfcd537a0b82160

8337274: Remove repeated 'the' in StyleSheet.create{Small,Large}AttributeSet

Reviewed-by: achung, honkar, prr

! src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java

Changeset: f2e1205a
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-08-02 15:51:26 +0000
URL:       https://git.openjdk.org/leyden/commit/f2e1205abf915c7f036c58292c6f4d8602cb0e64

8337676: JFR: Change the label of the throttle setting

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottleSetting.java

Changeset: 7deee745
Branch: premain
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2024-08-02 17:53:23 +0000
URL:       https://git.openjdk.org/leyden/commit/7deee745254e5f32b75a09d84ac5078a122c8b8d

8335122: Reorganize internal low-level support for HTML in jdk.javadoc

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractOverviewIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllPackagesIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DocFilesHandler.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ExternalSpecsWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Headings.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIndexBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlLinkFactory.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlLinkInfo.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexRedirectWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MarkerComments.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NewAPIListWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageTreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PreviewListWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/RestrictedListWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SearchWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerialFieldWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerialMethodWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SubWriterHolderWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SystemPropertiesWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TableHeader.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TableOfContents.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/BodyContents.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Head.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlAttr.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlDocument.java
= src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyles.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Links.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/TagName.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/package-info.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/BaseTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/DeprecatedTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/DocRootTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/IndexTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/InheritDocTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/LinkTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/LiteralTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/ParamTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/ReturnTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/SeeTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/SimpleTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/SnippetTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/SpecTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/SummaryTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/SystemPropertyTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/Taglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/TagletWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/ThrowsTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/UserTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/ValueTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java
= src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/Comment.java
= src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/Content.java
= src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/ContentBuilder.java
= src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/DocType.java
= src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/Entity.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlAttr.java
= src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlId.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlStyle.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlTag.java
= src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlTree.java
= src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/ListBuilder.java
= src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/RawHtml.java
= src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/Script.java
= src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/Text.java
= src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/TextBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/package-info.java
! test/langtools/jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java
! test/langtools/jdk/javadoc/doclet/testHtmlDocument/TestHtmlDocument.java
! test/langtools/jdk/javadoc/doclet/testHtmlTableStyles/TestHtmlTableStyles.java
! test/langtools/jdk/javadoc/doclet/testVoidHtmlElements/TestVoidHtmlElements.java
! test/langtools/tools/doclint/CoverageExtras.java
! test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.java
! test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.out
! test/langtools/tools/doclint/html/OtherTagsTest.java
! test/langtools/tools/doclint/html/OtherTagsTest.out

Changeset: 34edc735
Branch: premain
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-08-03 06:21:28 +0000
URL:       https://git.openjdk.org/leyden/commit/34edc7358f733cdf433d0ff50921bcb5a94c5e35

8337396: Cleanup usage of ExternalAddess

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

! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp
! src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/share/code/oopRecorder.cpp

Changeset: 367e0a65
Branch: premain
Author:    fabioromano1 <51378941+fabioromano1 at users.noreply.github.com>
Committer: Raffaello Giulietti <rgiulietti at openjdk.org>
Date:      2024-08-03 13:08:54 +0000
URL:       https://git.openjdk.org/leyden/commit/367e0a65561f95aad61b40930d5f46843fee3444

8334755: Asymptotically faster implementation of square root algorithm

Reviewed-by: rgiulietti

! src/java.base/share/classes/java/math/BigInteger.java
! src/java.base/share/classes/java/math/MutableBigInteger.java
! test/jdk/java/math/BigInteger/BigIntegerTest.java
+ test/micro/org/openjdk/bench/java/math/BigIntegerSquareRoot.java

Changeset: 8bd3cd51
Branch: premain
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-08-04 15:42:51 +0000
URL:       https://git.openjdk.org/leyden/commit/8bd3cd51562ff9e76fa0e3d49d38e6e19210f878

8337716: ByteBuffer hashCode implementations are inconsistent

Reviewed-by: alanb, liach

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

Changeset: dabdae6b
Branch: premain
Author:    Julian Waters <jwaters at openjdk.org>
Date:      2024-08-05 05:13:08 +0000
URL:       https://git.openjdk.org/leyden/commit/dabdae6b355b3e7a2795f6b01ba475652d483288

8334599: Improve code from JDK-8302671

Reviewed-by: aivanov, stuefe, prr

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

Changeset: fbe8a81d
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-08-05 05:57:41 +0000
URL:       https://git.openjdk.org/leyden/commit/fbe8a81d1900d0de1920ad1df6ad574f3da4bd51

8333144: docker tests do not work when ubsan is configured

Reviewed-by: clanger, stuefe

! test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java

Changeset: be34730f
Branch: premain
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-08-05 09:52:07 +0000
URL:       https://git.openjdk.org/leyden/commit/be34730fb4e6818ac13c46b34b735c967351e5cd

8335257: Refactor code to create Initialized Assertion Predicates into separate class

Reviewed-by: kvn, epeter

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

Changeset: d3e7b0c1
Branch: premain
Author:    Viktor Klang <vklang at openjdk.org>
Date:      2024-08-05 10:56:21 +0000
URL:       https://git.openjdk.org/leyden/commit/d3e7b0c12afde03985f1b06e6e7d789928971090

8336462: ConcurrentSkipListSet Javadoc incorrectly warns about size method complexity

Reviewed-by: jpai

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

Changeset: 2e093b06
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-08-05 13:17:32 +0000
URL:       https://git.openjdk.org/leyden/commit/2e093b06916b72b4feae5635aa8c5aa90679172b

8337779: test/jdk/jdk/jfr/jvm/TestHiddenWait.java is a bit fragile

Reviewed-by: mgronlun

! test/jdk/jdk/jfr/jvm/TestHiddenWait.java

Changeset: 7e925d72
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-05 14:05:00 +0000
URL:       https://git.openjdk.org/leyden/commit/7e925d727f716e5c366b0d85b9c0de24efe43103

8337283: configure.log is truncated when build dir is on different filesystem

Reviewed-by: phh, stuefe, clanger, ihse

! make/autoconf/configure.ac

Changeset: c095c0e6
Branch: premain
Author:    Carlo Refice <carlo.refice at oracle.com>
Date:      2024-08-05 14:09:54 +0000
URL:       https://git.openjdk.org/leyden/commit/c095c0e6a58b1665d51ff19381e32f168e99e8f5

8336489: Track scoped accesses in JVMCI compiled code

Reviewed-by: dnsimon, never

! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/jvmci/jvmciRuntime.hpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotCompiledCodeStream.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotCompiledNmethod.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfig.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ResolvedJavaMethod.java
! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java
! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TypeUniverse.java

Changeset: 97afbd96
Branch: premain
Author:    Johan Sj?len <jsjolen at openjdk.org>
Date:      2024-08-05 14:49:38 +0000
URL:       https://git.openjdk.org/leyden/commit/97afbd9603ba8ec1956c4cedf542667d33988661

8336410: runtime/NMT/TotalMallocMmapDiffTest.java Total malloc diff is incorrect. Expected malloc diff range

Reviewed-by: gziemski, stuefe

! test/hotspot/jtreg/runtime/NMT/TotalMallocMmapDiffTest.java

Changeset: 219e1eb1
Branch: premain
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-08-05 15:06:38 +0000
URL:       https://git.openjdk.org/leyden/commit/219e1eb13a688532705e603e276799c0157f5f28

8337712: Wrong javadoc in java.util.Date#toString(): "61" and right parenthesis

Reviewed-by: rgiulietti

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

Changeset: 98562166
Branch: premain
Author:    Zdenek Zambersky <zzambers at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-08-05 15:09:45 +0000
URL:       https://git.openjdk.org/leyden/commit/98562166e4a4c8921709014423c6cbc993aa0d97

8336928: GHA: Bundle artifacts removal broken

Reviewed-by: ihse

! .github/workflows/main.yml

Changeset: e68df528
Branch: premain
Author:    Damon Nguyen <dnguyen at openjdk.org>
Date:      2024-08-05 16:48:18 +0000
URL:       https://git.openjdk.org/leyden/commit/e68df528f80cff3a5564a12b7ec71a920800ce28

8337054: JDK 23 RDP2 L10n resource files update

Reviewed-by: naoto, jlu

! 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/launcher_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

Changeset: 807186ff
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-08-05 16:53:30 +0000
URL:       https://git.openjdk.org/leyden/commit/807186ffc6a0a9f2515a66329c2a98a43385463c

8337784: Fix simple -Wzero-as-null-pointer-constant warnings in linux/posix code

Reviewed-by: stefank, shade

! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/posix/perfMemory_posix.cpp
! src/hotspot/os/posix/signals_posix.cpp

Changeset: 42652b2e
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-08-05 16:57:11 +0000
URL:       https://git.openjdk.org/leyden/commit/42652b2e5350bcab6fceb0148be8bf3d65a0e173

8337787: Fix -Wzero-as-null-pointer-constant warnings when JVMTI feature is disabled

Reviewed-by: ayang, sspitsyn

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

Changeset: 08f697f4
Branch: premain
Author:    Christoph Langer <clanger at openjdk.org>
Date:      2024-08-05 17:58:12 +0000
URL:       https://git.openjdk.org/leyden/commit/08f697f4fcbcdd912c3aa5f331fbf8212906465f

8337819: Update GHA JDKs to 22.0.2

Reviewed-by: mbaesken, ihse, shade

! make/conf/github-actions.conf

Changeset: e2c07d50
Branch: premain
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-08-05 18:42:27 +0000
URL:       https://git.openjdk.org/leyden/commit/e2c07d5044587476fc0fff14260e2b73816d2062

8337299: vmTestbase/nsk/jdb/stop_at/stop_at002/stop_at002.java failure goes undetected

Reviewed-by: amenkov, sspitsyn

! test/hotspot/jtreg/vmTestbase/nsk/jdb/stop_at/stop_at002/stop_at002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/stop_at/stop_at002/stop_at002a.java

Changeset: 431d4f7e
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-08-05 19:53:49 +0000
URL:       https://git.openjdk.org/leyden/commit/431d4f7e18369466eedd00926a5162a1461d0b25

8337785: Fix simple -Wzero-as-null-pointer-constant warnings in x86 code

Reviewed-by: jwaters, ayang, shade

! src/hotspot/cpu/x86/frame_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp
! src/hotspot/cpu/x86/methodHandles_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.cpp
! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp

Changeset: 7146daee
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-08-05 20:05:07 +0000
URL:       https://git.openjdk.org/leyden/commit/7146daee68788bf9a33d6eed6fb0614a82644cbc

8337783: Use THROW_NULL instead of THROW_0 in pointer contexts in misc runtime code

Reviewed-by: stefank, shade

! src/hotspot/os/posix/perfMemory_posix.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/oops/objArrayKlass.cpp
! src/hotspot/share/runtime/perfData.cpp
! src/hotspot/share/runtime/reflection.cpp

Changeset: 965d6b9c
Branch: premain
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2024-08-05 23:29:17 +0000
URL:       https://git.openjdk.org/leyden/commit/965d6b9cbe2dd882fe3c3c955dfa08685af7d6c2

8335836: serviceability/jvmti/StartPhase/AllowedFunctions/AllowedFunctions.java fails with unexpected exit code: 112

Reviewed-by: cjplummer, amenkov

! test/hotspot/jtreg/serviceability/jvmti/StartPhase/AllowedFunctions/libAllowedFunctions.c

Changeset: 73718fb8
Branch: premain
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2024-08-06 02:16:19 +0000
URL:       https://git.openjdk.org/leyden/commit/73718fb8a3570023e7855137eb008f78b8a1e8ce

8337788: RISC-V: Cleanup code in MacroAssembler::reserved_stack_check

Reviewed-by: fyang, rehn, fjiang

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

Changeset: 20575949
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-08-06 05:34:33 +0000
URL:       https://git.openjdk.org/leyden/commit/20575949612a750a428316635715737183a2d58c

8337782: Use THROW_NULL instead of THROW_0 in pointer contexts in prims code

Reviewed-by: shade, dholmes

! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/nativeLookup.cpp
! src/hotspot/share/prims/perf.cpp
! src/hotspot/share/prims/unsafe.cpp
! src/hotspot/share/prims/whitebox.cpp

Changeset: 0d8ec429
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-08-06 06:59:11 +0000
URL:       https://git.openjdk.org/leyden/commit/0d8ec42969fb60c140aaed7795ea1b9591915b8d

8337642: Remove unused APIs of GCPolicyCounters

Reviewed-by: tschatzl

! src/hotspot/share/gc/parallel/gcAdaptivePolicyCounters.hpp
! src/hotspot/share/gc/parallel/psGCAdaptivePolicyCounters.hpp
! src/hotspot/share/gc/serial/defNewGeneration.cpp
! src/hotspot/share/gc/shared/gcPolicyCounters.hpp

Changeset: f92c60e1
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-08-06 07:06:43 +0000
URL:       https://git.openjdk.org/leyden/commit/f92c60e1a9968620cbc92b52aa546b57c09da487

8337810: ProblemList BasicDirectoryModel/LoaderThreadCount.java on Windows

Reviewed-by: clanger

! test/jdk/ProblemList.txt

Changeset: 958786b2
Branch: premain
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-08-06 09:07:44 +0000
URL:       https://git.openjdk.org/leyden/commit/958786b28ffb532b38746640b6fc11242f056ad9

8332522: SwitchBootstraps::mappedEnumLookup constructs unused array

Reviewed-by: liach, redestad

! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
+ test/micro/org/openjdk/bench/java/lang/runtime/SwitchEnum.java

Changeset: f9b8a220
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-08-06 09:28:12 +0000
URL:       https://git.openjdk.org/leyden/commit/f9b8a22062c7ad7ffb150394da6b3ab069785535

8337798: JFR: Remove jdk/jfr/api/consumer/recordingstream/TestOnEvent.java from ProblemList.txt

Reviewed-by: mgronlun

! test/jdk/ProblemList.txt

Changeset: a117945d
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-08-06 09:37:21 +0000
URL:       https://git.openjdk.org/leyden/commit/a117945d5a704781944ae15c852c31d090f03adb

8337344: Redundant javadoc at RasterPrinterJob.isCancelled

Reviewed-by: aivanov, prr

! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java

Changeset: ef909bdf
Branch: premain
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2024-08-06 11:32:24 +0000
URL:       https://git.openjdk.org/leyden/commit/ef909bdf7f08dfd67bac2665aa85f86c0e303db9

8335121: Native memory leak when not recording any events

Reviewed-by: egahlin, shade

! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp

Changeset: 1348ece6
Branch: premain
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-08-06 11:34:57 +0000
URL:       https://git.openjdk.org/leyden/commit/1348ece6df7b460501931533c238e819995a2086

8332120: Potential compilation failure in istream.cpp:205 - loss of data on conversion

Reviewed-by: dholmes, iklam

! src/hotspot/share/utilities/istream.cpp
! src/hotspot/share/utilities/istream.hpp

Changeset: ab509f1b
Branch: premain
Author:    Andrew Dinn <adinn at openjdk.org>
Date:      2024-08-06 13:22:55 +0000
URL:       https://git.openjdk.org/leyden/commit/ab509f1b98329b1624a3111e226b640ee76f5969

8337654: Relocate uncommon trap stub from SharedRuntime to OptoRuntime

Reviewed-by: kvn, vlivanov, fyang

! src/hotspot/cpu/aarch64/runtime_aarch64.cpp
! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/arm/runtime_arm.cpp
! src/hotspot/cpu/arm/sharedRuntime_arm.cpp
! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
+ src/hotspot/cpu/riscv/runtime_riscv.cpp
! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp
! src/hotspot/cpu/s390/sharedRuntime_s390.cpp
! src/hotspot/cpu/x86/runtime_x86_32.cpp
! src/hotspot/cpu/x86/runtime_x86_64.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/lcm.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/opto/runtime.cpp
! src/hotspot/share/opto/runtime.hpp
! src/hotspot/share/opto/stringopts.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/sharedRuntime.hpp

Changeset: 53db937d
Branch: premain
Author:    Feilong Jiang <fjiang at openjdk.org>
Date:      2024-08-06 14:01:23 +0000
URL:       https://git.openjdk.org/leyden/commit/53db937dd0766695906dc20c1dbbd3228c02fe1e

8337780: RISC-V: C2: Change C calling convention for sp to NS

Reviewed-by: fyang, rehn

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

Changeset: 3f8b3e55
Branch: premain
Author:    Doug Simon <dnsimon at openjdk.org>
Date:      2024-08-06 16:37:59 +0000
URL:       https://git.openjdk.org/leyden/commit/3f8b3e55276336cbb814d3b746d4337678389969

8337887: [JVMCI] Clarify jdk.vm.ci.code.Architecture.getName javadoc

Reviewed-by: never

! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/aarch64/AArch64.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/amd64/AMD64.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/Architecture.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/riscv64/RISCV64.java

Changeset: ff634a96
Branch: premain
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-08-06 20:11:21 +0000
URL:       https://git.openjdk.org/leyden/commit/ff634a967027cfa56b666d31c45db9a4acc09ea4

8337506: Disable "best-fit" mapping on Windows command line

Reviewed-by: alanb

! src/java.base/share/native/launcher/main.c
+ test/jdk/tools/launcher/DisableBestFitMappingTest.java

Changeset: 22a34213
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-08-06 20:15:47 +0000
URL:       https://git.openjdk.org/leyden/commit/22a3421379162bb302fb8e5ccc315e53d95b6245

8337786: Fix simple -Wzero-as-null-pointer-constant warnings in aarch64 code

Reviewed-by: shade, tschatzl

! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp
! src/hotspot/cpu/aarch64/frame_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp
! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp

Changeset: fc652d2a
Branch: premain
Author:    Alisen Chung <achung at openjdk.org>
Date:      2024-08-06 21:10:06 +0000
URL:       https://git.openjdk.org/leyden/commit/fc652d2a58bfd99b05011c051e5710d1dac049ab

8235404: [macos] JOptionPane blocks drawing string on another component

Reviewed-by: honkar, dnguyen

! src/java.desktop/share/classes/javax/swing/JOptionPane.java
+ test/jdk/javax/swing/JOptionPane/OptionPaneInput.java

Changeset: 6733b89d
Branch: premain
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-08-06 21:44:30 +0000
URL:       https://git.openjdk.org/leyden/commit/6733b89de1ed9ebcc1e8a8271970048ad0f0aac3

8337667: sun/tools/jcmd/TestJcmdPIDSubstitution.java is failing on mac and windows

Reviewed-by: stuefe, kevinw

! test/jdk/sun/tools/jcmd/TestJcmdPIDSubstitution.java

Changeset: 920751e5
Branch: premain
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2024-08-06 21:56:48 +0000
URL:       https://git.openjdk.org/leyden/commit/920751e5d5838dab90438117a77f43876902eb72

8311990: Two JDI tests may interfere with each other

Reviewed-by: dholmes, sspitsyn

! test/jdk/com/sun/jdi/JdwpListenTest.java
! test/jdk/com/sun/jdi/JdwpNetProps.java

Changeset: 66286b25
Branch: premain
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2024-08-07 05:32:28 +0000
URL:       https://git.openjdk.org/leyden/commit/66286b25a183de2ffd0689da9c2bd1978b881aa7

8337968: Problem list compiler/vectorapi/VectorRebracket128Test.java

Reviewed-by: chagedorn

! test/hotspot/jtreg/ProblemList.txt

Changeset: 41f784fe
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-08-07 07:48:05 +0000
URL:       https://git.openjdk.org/leyden/commit/41f784fe63f8e06a25e1fe00dc96e398874adf81

8335925: Serial: Move allocation API from Generation to subclasses

Reviewed-by: gli, kbarrett, iwalulya

! src/hotspot/share/gc/serial/defNewGeneration.cpp
! src/hotspot/share/gc/serial/defNewGeneration.hpp
! src/hotspot/share/gc/serial/generation.hpp
! src/hotspot/share/gc/serial/serialHeap.cpp
! src/hotspot/share/gc/serial/tenuredGeneration.cpp
! src/hotspot/share/gc/serial/tenuredGeneration.hpp
! src/hotspot/share/gc/serial/tenuredGeneration.inline.hpp

Changeset: 88a05a85
Branch: premain
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2024-08-07 10:24:34 +0000
URL:       https://git.openjdk.org/leyden/commit/88a05a853ed9e0425ba3315b751a5015bed62675

8337975: [BACKOUT] Native memory leak when not recording any events

Reviewed-by: jpai, egahlin

! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp

Changeset: 21f710e7
Branch: premain
Author:    Joel Sikstr?m <joel.sikstrom at oracle.com>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-08-07 14:16:01 +0000
URL:       https://git.openjdk.org/leyden/commit/21f710e7f6698b12b06cc3685cefa31f5fcff2a2

8310675: Fix -Wconversion warnings in ZGC code

Reviewed-by: stefank, ayang

! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
! src/hotspot/share/gc/z/zArguments.cpp
! src/hotspot/share/gc/z/zArray.inline.hpp
! src/hotspot/share/gc/z/zBarrier.cpp
! src/hotspot/share/gc/z/zBarrierSetNMethod.cpp
! src/hotspot/share/gc/z/zCPU.inline.hpp
! src/hotspot/share/gc/z/zDirector.cpp
! src/hotspot/share/gc/z/zForwardingAllocator.inline.hpp
! src/hotspot/share/gc/z/zGeneration.cpp
! src/hotspot/share/gc/z/zGeneration.hpp
! src/hotspot/share/gc/z/zHeapIterator.cpp
! src/hotspot/share/gc/z/zHeuristics.cpp
! src/hotspot/share/gc/z/zIndexDistributor.inline.hpp
! src/hotspot/share/gc/z/zLiveMap.cpp
! src/hotspot/share/gc/z/zLiveMap.hpp
! src/hotspot/share/gc/z/zMarkCache.cpp
! src/hotspot/share/gc/z/zMarkStack.cpp
! src/hotspot/share/gc/z/zMetronome.cpp
! src/hotspot/share/gc/z/zNMethod.cpp
! src/hotspot/share/gc/z/zNMethodTable.cpp
! src/hotspot/share/gc/z/zObjArrayAllocator.cpp
! src/hotspot/share/gc/z/zPage.inline.hpp
! src/hotspot/share/gc/z/zPageCache.cpp
! src/hotspot/share/gc/z/zPageTable.inline.hpp
! src/hotspot/share/gc/z/zRelocationSet.cpp
! src/hotspot/share/gc/z/zRelocationSetSelector.cpp
! src/hotspot/share/gc/z/zStat.cpp
! src/hotspot/share/gc/z/zStat.hpp
! src/hotspot/share/gc/z/zStoreBarrierBuffer.cpp
! src/hotspot/share/gc/z/zStoreBarrierBuffer.hpp
! src/hotspot/share/gc/z/zStoreBarrierBuffer.inline.hpp
! src/hotspot/share/gc/z/zUnmapper.cpp
! src/hotspot/share/gc/z/zVerify.cpp

Changeset: d19ba81c
Branch: premain
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-08-07 15:58:03 +0000
URL:       https://git.openjdk.org/leyden/commit/d19ba81ce12a99de1114c1bfe67392f5aee2104e

8337603: Change in behavior with -Djava.locale.useOldISOCodes=true

Reviewed-by: iris, bpb

! src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java
! test/jdk/java/util/Locale/LocaleTest.java

Changeset: 36d08c21
Branch: premain
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2024-08-07 17:41:23 +0000
URL:       https://git.openjdk.org/leyden/commit/36d08c213d03deddf69ecb9770a3afef73a15444

8336846: assert(state->get_thread() == jt) failed: handshake unsafe conditions

Reviewed-by: amenkov, dholmes, cjplummer, pchilanomate, lmesnik

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

Changeset: a5c2d7b3
Branch: premain
Author:    Fernando Guallini <fguallini at openjdk.org>
Committer: Rajan Halade <rhalade at openjdk.org>
Date:      2024-08-07 18:24:08 +0000
URL:       https://git.openjdk.org/leyden/commit/a5c2d7b305407974b3f67c48b8dcb1f8e77abde3

8335172: Add manual steps to run security/auth/callback/TextCallbackHandler/Password.java test

Reviewed-by: rhalade

! test/jdk/ProblemList.txt
! test/jdk/TEST.groups
! test/jdk/com/sun/security/auth/callback/TextCallbackHandler/Password.java

Changeset: 5e021cbc
Branch: premain
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-08-07 20:25:51 +0000
URL:       https://git.openjdk.org/leyden/commit/5e021cbcc7a6cb30a27380950e115ff12846239c

8337410: The makefiles should set problemlist and adjust timeout basing on the given VM flags

Reviewed-by: ihse

! make/RunTests.gmk

Changeset: 9b11bd7f
Branch: premain
Author:    Jamil Nimeh <jnimeh at openjdk.org>
Date:      2024-08-07 21:06:47 +0000
URL:       https://git.openjdk.org/leyden/commit/9b11bd7f4a511ddadf9f02e82aab6ba78beb6763

8337826: Improve logging in OCSPTimeout and SimpleOCSPResponder to help diagnose JDK-8309754

Reviewed-by: mullan

! test/jdk/java/security/cert/CertPathValidator/OCSP/OCSPTimeout.java
! test/jdk/java/security/testlibrary/SimpleOCSPServer.java

Changeset: 16df9c33
Branch: premain
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2024-08-08 05:22:20 +0000
URL:       https://git.openjdk.org/leyden/commit/16df9c33e9bbc9329ae60ba14332c09aadaba3f0

8337971: Problem list several jvmci tests on linux-riscv64 until JDK-8331704 is fixed

Reviewed-by: fyang, shade

! test/hotspot/jtreg/ProblemList.txt

Changeset: 1846a65e
Branch: premain
Author:    Turkhan Badalov <badalov.turxan at gmail.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-08-08 05:34:32 +0000
URL:       https://git.openjdk.org/leyden/commit/1846a65e32624f6da691c1072f44fcb762b43233

8337205: Typo in Stack vs Deque Method table in Deque specification

Reviewed-by: liach

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

Changeset: fa183590
Branch: premain
Author:    Afshin Zafari <azafari at openjdk.org>
Date:      2024-08-08 08:55:05 +0000
URL:       https://git.openjdk.org/leyden/commit/fa18359007bd80d2e74c07a5a1ea6170e1bd474d

8335981: ProblemList runtime/Thread/TestAlwaysPreTouchStacks.java for MacOS

Reviewed-by: tschatzl

! test/hotspot/jtreg/ProblemList.txt

Changeset: a9460a69
Branch: premain
Author:    Casper Norrbin <casper.norrbin at oracle.com>
Committer: Stefan Karlsson <stefank at openjdk.org>
Date:      2024-08-08 10:38:02 +0000
URL:       https://git.openjdk.org/leyden/commit/a9460a69e74f876274ec64394ac6504580041b21

8337982: Remove dead undef assrt0n

Reviewed-by: stefank, dholmes

! src/hotspot/share/memory/metaspace/blockTree.cpp

Changeset: 3bc4a1ac
Branch: premain
Author:    Tejesh R <tr at openjdk.org>
Date:      2024-08-08 10:40:56 +0000
URL:       https://git.openjdk.org/leyden/commit/3bc4a1acc4bb1885ddba69283b99bbe02f8e43b7

8233068: HIDPI: Linux: AWT Checkbox check mark is unscaled

Reviewed-by: jdv, abhiscxk, honkar

! src/java.desktop/unix/classes/sun/awt/X11/XCheckboxPeer.java
+ test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java

Changeset: 088871ce
Branch: premain
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
Date:      2024-08-08 10:51:47 +0000
URL:       https://git.openjdk.org/leyden/commit/088871ce36f85fb30b24c49146f547bc8e2b0dcb

8335267: [XWayland] move screencast tokens from .awt to .java folder

Reviewed-by: prr, avu

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

Changeset: 12c553f1
Branch: premain
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
Date:      2024-08-08 10:51:58 +0000
URL:       https://git.openjdk.org/leyden/commit/12c553f12876b4095685676f800119c0e275bf44

8329471: Remove GTK2

Reviewed-by: abhiscxk, prr, ihse

! make/modules/java.desktop/lib/AwtLibraries.gmk
! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKEngine.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKIconFactory.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java
! src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java
- src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c
- src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.h
! src/java.desktop/unix/native/libawt_xawt/awt/gtk_interface.c
! src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c
! test/jdk/java/awt/Gtk/GtkVersionTest/GtkVersionTest.java
! test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureGtkTest.java
! test/jdk/javax/swing/LookAndFeel/8145547/DemandGTK.java
- test/jdk/javax/swing/LookAndFeel/8145547/DemandGTK2.sh
- test/jdk/javax/swing/LookAndFeel/8145547/DemandGTK2.txt
! test/jdk/javax/swing/LookAndFeel/8145547/DemandGTK3.sh

Changeset: ddbd7a78
Branch: premain
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
Date:      2024-08-08 10:53:23 +0000
URL:       https://git.openjdk.org/leyden/commit/ddbd7a78f191462695ecbeeef7fd6312e322b15a

8337320: Update ProblemList.txt with tests known to fail on XWayland

Reviewed-by: prr

! test/jdk/ProblemList.txt

Changeset: 4b740d87
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-08-08 10:57:43 +0000
URL:       https://git.openjdk.org/leyden/commit/4b740d87ee50ba49305add4aae6490bebb6963ba

8225209: jdk/jfr/event/compiler/TestCodeSweeper.java fails

Reviewed-by: mgronlun

! test/jdk/ProblemList.txt
! test/jdk/jdk/jfr/event/compiler/TestCodeSweeper.java

Changeset: 6a9a867d
Branch: premain
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2024-08-08 14:38:46 +0000
URL:       https://git.openjdk.org/leyden/commit/6a9a867d645b8fe86f4ca2b04a43bf5aa8f9d487

8337994: [REDO] Native memory leak when not recording any events

Reviewed-by: egahlin

! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp
! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp

Changeset: 78773b17
Branch: premain
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-08-08 15:52:17 +0000
URL:       https://git.openjdk.org/leyden/commit/78773b1769922611318243b6680d59518ed4e015

8338015: Fix "Java Java" typo in package info file of java.lang.classfile

Reviewed-by: jiefu, jpai, liach

! src/java.base/share/classes/java/lang/classfile/package-info.java

Changeset: 9695f095
Branch: premain
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-08-08 16:11:08 +0000
URL:       https://git.openjdk.org/leyden/commit/9695f09581bac856ad97943cca15c65dc21d2adf

8337683: Fix -Wconversion problem with arrayOop.hpp

Reviewed-by: stefank, dholmes

! src/hotspot/share/oops/arrayOop.hpp
! src/hotspot/share/runtime/atomic.hpp
! src/hotspot/share/utilities/byteswap.hpp

Changeset: 53c9f037
Branch: premain
Author:    Jiangli Zhou <jiangli at openjdk.org>
Date:      2024-08-08 16:31:02 +0000
URL:       https://git.openjdk.org/leyden/commit/53c9f037fb2805aab5ab9729166ce7d5bc7a77f9

8336849: Remove .llvm_addrsig section from JDK/VM static libraries (.a files)

Reviewed-by: ihse

! make/common/native/Link.gmk

Changeset: bfb75b96
Branch: premain
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2024-08-08 16:53:38 +0000
URL:       https://git.openjdk.org/leyden/commit/bfb75b96266f4c5840e2edea13f9aa2c801518cf

8336926: jdk/internal/util/ReferencedKeyTest.java can fail with ConcurrentModificationException

Reviewed-by: bpb, shade, dfuchs

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

Changeset: e7a0b5b0
Branch: premain
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2024-08-08 18:45:11 +0000
URL:       https://git.openjdk.org/leyden/commit/e7a0b5b09bcfcd8b09667e51ec588e206f0652ff

8334780: Crash: assert(h_array_list.not_null()) failed: invariant

Reviewed-by: egahlin, shade

! src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp

Changeset: 9f08a01c
Branch: premain
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-08-08 19:47:50 +0000
URL:       https://git.openjdk.org/leyden/commit/9f08a01cb6ebb08f67749aabdff4efaedfaf3228

8338010: WB_IsFrameDeoptimized miss ResourceMark

Reviewed-by: dholmes, shade

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

Changeset: 55c50970
Branch: premain
Author:    Jiawei Tang <jwtang at openjdk.org>
Date:      2024-08-09 02:29:15 +0000
URL:       https://git.openjdk.org/leyden/commit/55c509708e9b89a7609fd41b6e5a271f250bbacd

8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option

Reviewed-by: dholmes, sspitsyn

! src/hotspot/share/prims/jvmtiExport.cpp
+ test/hotspot/jtreg/serviceability/jvmti/vthread/TestPinCaseWithCFLH/TestPinCaseWithCFLH.java

Changeset: 0c1e9111
Branch: premain
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2024-08-09 02:59:37 +0000
URL:       https://git.openjdk.org/leyden/commit/0c1e9111d226b601236b9826e27ecc67a8b625fb

8338019: Fix simple -Wzero-as-null-pointer-constant warnings in riscv code

Reviewed-by: fyang, mli, luhenry

! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp
! src/hotspot/cpu/riscv/c1_Runtime1_riscv.cpp
! src/hotspot/cpu/riscv/frame_riscv.cpp
! src/hotspot/cpu/riscv/nativeInst_riscv.cpp

Changeset: 9ab8c6b9
Branch: premain
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Date:      2024-08-09 05:09:27 +0000
URL:       https://git.openjdk.org/leyden/commit/9ab8c6b9ba90ffd12600a250c8704571e9feb78d

8335130: The test "javax/swing/plaf/synth/ComponentsOrientationSupport/5033822/bug5033822.java" fails because the background color of the tabs is displayed incorrectly.

Reviewed-by: achung, psadhukhan

! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java
! src/java.desktop/share/classes/javax/swing/plaf/nimbus/SynthPainterImpl.java
! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java

Changeset: 00aac409
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-08-09 06:26:22 +0000
URL:       https://git.openjdk.org/leyden/commit/00aac4097abd3c5e6144734cfd44228bc31892fb

8338058: map_or_reserve_memory_aligned Windows enhance remap assertion

Reviewed-by: mdoerr, clanger

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

Changeset: c01f53ac
Branch: premain
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-08-09 07:17:59 +0000
URL:       https://git.openjdk.org/leyden/commit/c01f53ac2dab1d4d2cd1e4d45a67f9373d4a9c7e

8337876: [IR Framework] Add support for IR tests with @Stable

Reviewed-by: shade, kvn

! test/hotspot/jtreg/compiler/lib/ir_framework/README.md
! test/hotspot/jtreg/compiler/lib/ir_framework/TestFramework.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/TestVMProcess.java
! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java
+ test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestPrivilegedMode.java

Changeset: 82d5768c
Branch: premain
Author:    Andrey Turbanov <aturbanov at openjdk.org>
Date:      2024-08-09 07:20:01 +0000
URL:       https://git.openjdk.org/leyden/commit/82d5768c1bdccfaf97a41f32a8bfcfd03a0fb378

8337840: Remove redundant null check in ObjectOutputStream.writeProxyDesc

Reviewed-by: rriggs

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

Changeset: f74109bd
Branch: premain
Author:    Joel Sikstr?m <joel.sikstrom at oracle.com>
Date:      2024-08-09 07:29:56 +0000
URL:       https://git.openjdk.org/leyden/commit/f74109bd178c92a9dff1ca6fce03b25f51a0384f

8337939: ZGC: Make assertions and checks less convoluted and explicit

Reviewed-by: stefank, ayang, eosterlund

! src/hotspot/share/gc/z/zAddress.cpp
! src/hotspot/share/gc/z/zAddress.inline.hpp
! src/hotspot/share/gc/z/zBarrier.inline.hpp
! src/hotspot/share/gc/z/zBarrierSet.inline.hpp
! src/hotspot/share/gc/z/zHeapIterator.cpp
! src/hotspot/share/gc/z/zMark.cpp
! src/hotspot/share/gc/z/zMark.inline.hpp
! src/hotspot/share/gc/z/zPage.inline.hpp
! src/hotspot/share/gc/z/zReferenceProcessor.cpp
! src/hotspot/share/gc/z/zVerify.cpp

Changeset: 53fce38a
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-08-09 07:53:15 +0000
URL:       https://git.openjdk.org/leyden/commit/53fce38a3ff8700fef640fffc066efc21ff9c25f

8338062: JFR: Remove TestStartDuration.java and TestStartName.java from ProblemList.txt

Reviewed-by: mgronlun

! test/jdk/ProblemList.txt

Changeset: 6ebd5d74
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-08-09 08:23:44 +0000
URL:       https://git.openjdk.org/leyden/commit/6ebd5d74d57b334e7cf0b1282d7bb469a56fb3d6

8338036: Serial: Remove Generation::update_counters

Reviewed-by: kbarrett

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

Changeset: c37e8638
Branch: premain
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-08-09 09:12:41 +0000
URL:       https://git.openjdk.org/leyden/commit/c37e8638c98cb4516569304e9a0ab477affb0641

8314125: RISC-V: implement Base64 intrinsic - encoding

Reviewed-by: fyang, luhenry

! src/hotspot/cpu/riscv/assembler_riscv.hpp
! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp
! src/hotspot/cpu/riscv/vm_version_riscv.cpp

Changeset: 14071607
Branch: premain
Author:    Hannes Walln?fer <hannesw at openjdk.org>
Date:      2024-08-09 09:24:50 +0000
URL:       https://git.openjdk.org/leyden/commit/140716078694a338e2c2f837841761262cee5542

8313931: Javadoc: links to type parameters actually generate links to classes

Reviewed-by: jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlLinkFactory.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script.js.template
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/stylesheet.css
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/LinkTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/ParamTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java
! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java
! test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java
! test/langtools/jdk/javadoc/doclet/testErasure/TestErasure.java
! test/langtools/jdk/javadoc/doclet/testGenericMethodLinkTaglet/TestGenericMethodLinkTaglet.java
! test/langtools/jdk/javadoc/doclet/testHref/TestHref.java
! test/langtools/jdk/javadoc/doclet/testInterface/TestInterface.java
+ test/langtools/jdk/javadoc/doclet/testLinkTaglet/TestLinkTagletTypeParam.java
! test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java
! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java
! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java
! test/langtools/jdk/javadoc/doclet/testParamTaglet/TestParamTaglet.java
! test/langtools/jdk/javadoc/doclet/testProperty/TestProperty.java
! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java
! test/langtools/jdk/javadoc/doclet/testSerializedForm/TestSerializedForm.java
! test/langtools/jdk/javadoc/doclet/testThrows/TestThrows.java
! test/langtools/jdk/javadoc/doclet/testTypeParams/TestTypeParameters.java
! test/langtools/jdk/javadoc/doclet/testTypeParams/pkg/CtorTypeParam.java
! test/langtools/jdk/javadoc/doclet/testUnicode/TestUnicode.java

Changeset: 2b5aec2a
Branch: premain
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
Date:      2024-08-09 11:28:59 +0000
URL:       https://git.openjdk.org/leyden/commit/2b5aec2aad3883d4d407ec3a572f78755d60190d

8338109: java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java duplicate in ProblemList

Reviewed-by: aivanov

! test/jdk/ProblemList.txt

Changeset: 069e0ea6
Branch: premain
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-08-09 12:00:15 +0000
URL:       https://git.openjdk.org/leyden/commit/069e0ea69f43960164d3e077d2c7b950cde77927

8338064: Give better error for ConcurrentHashTable corruption

Reviewed-by: dholmes, shade

! src/hotspot/share/utilities/concurrentHashTable.hpp
! src/hotspot/share/utilities/concurrentHashTable.inline.hpp
+ test/hotspot/jtreg/runtime/stringtable/StringTableCorruptionTest.java

Changeset: 3cf3f300
Branch: premain
Author:    Casper Norrbin <casper.norrbin at oracle.com>
Committer: Sonia Zaldana Calles <szaldana at openjdk.org>
Date:      2024-08-09 14:32:29 +0000
URL:       https://git.openjdk.org/leyden/commit/3cf3f300de1e9d2c8767877ed3a26679e34b7d22

8330191: Fix typo in precompiled.hpp

Reviewed-by: jsjolen, szaldana

! src/hotspot/share/precompiled/precompiled.hpp

Changeset: 60fa08fc
Branch: premain
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-08-09 17:08:19 +0000
URL:       https://git.openjdk.org/leyden/commit/60fa08fcfe5c6551ee3120330ade93e45df618c7

8337797: Additional ExternalAddress cleanup

Reviewed-by: adinn, thartmann

! src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp
! src/hotspot/cpu/riscv/jniFastGetField_riscv.cpp
! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/jniFastGetField_x86_32.cpp
! src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp
! src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp

Changeset: 358d77da
Branch: premain
Author:    Dmitry Chuyko <dchuyko at openjdk.org>
Date:      2024-08-09 17:56:37 +0000
URL:       https://git.openjdk.org/leyden/commit/358d77dafbe0e35d5b20340fccddc0fb8f3db82a

8337657: AArch64: No need for acquire fence in safepoint poll during JNI calls

Reviewed-by: phh

! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp

Changeset: 6a3d0452
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-08-11 18:34:18 +0000
URL:       https://git.openjdk.org/leyden/commit/6a3d045221c338fefec9bd59245324eae60b156b

8337709: Use allocated states for chunking large array processing

Reviewed-by: iwalulya, tschatzl

! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.hpp
+ src/hotspot/share/gc/shared/partialArrayState.cpp
+ src/hotspot/share/gc/shared/partialArrayState.hpp
! src/hotspot/share/gc/shared/partialArrayTaskStepper.cpp
! src/hotspot/share/gc/shared/partialArrayTaskStepper.hpp
! src/hotspot/share/gc/shared/partialArrayTaskStepper.inline.hpp
! src/hotspot/share/gc/shared/taskqueue.hpp
! test/hotspot/gtest/gc/shared/test_partialArrayTaskStepper.cpp

Changeset: 0e7c1c1a
Branch: premain
Author:    SendaoYan <syan at openjdk.org>
Committer: Jie Fu <jiefu at openjdk.org>
Date:      2024-08-12 06:26:27 +0000
URL:       https://git.openjdk.org/leyden/commit/0e7c1c1afeaba1c125b70cabe7b1b7a3193ee5c3

8338112: Test testlibrary_tests/ir_framework/tests/TestPrivilegedMode.java fails with release build

Reviewed-by: chagedorn, thartmann

! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestPrivilegedMode.java

Changeset: 692f5cbd
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-08-12 07:32:10 +0000
URL:       https://git.openjdk.org/leyden/commit/692f5cbdb9bd94f03e5f18ddf07d56fbb5c0d456

8338101: remove old remap assertion in map_or_reserve_memory_aligned  after JDK-8338058

Reviewed-by: mdoerr, clanger

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

Changeset: 03204600
Branch: premain
Author:    Andrew Haley <aph at openjdk.org>
Date:      2024-08-12 07:38:43 +0000
URL:       https://git.openjdk.org/leyden/commit/03204600c596214895ef86581eba9722f76d39b3

8337958: Out-of-bounds array access in secondary_super_cache

Reviewed-by: vlivanov, shade

! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/share/oops/klass.cpp

Changeset: a6c06307
Branch: premain
Author:    Joel Sikstr?m <joel.sikstrom at oracle.com>
Committer: Stefan Karlsson <stefank at openjdk.org>
Date:      2024-08-12 10:58:05 +0000
URL:       https://git.openjdk.org/leyden/commit/a6c0630737bbf2f2e6c64863ff9b43c50c4742b6

8337938: ZUtils::alloc_aligned allocates without reporting to NMT

Reviewed-by: stefank, kbarrett

- src/hotspot/os/posix/gc/z/zUtils_posix.cpp
- src/hotspot/os/windows/gc/z/zUtils_windows.cpp
! src/hotspot/share/gc/z/zStat.cpp
! src/hotspot/share/gc/z/zUtils.hpp
! src/hotspot/share/gc/z/zUtils.inline.hpp
! src/hotspot/share/gc/z/zValue.inline.hpp

Changeset: 89a15f14
Branch: premain
Author:    Daniel Gredler <daniel.gredler at gmail.com>
Committer: Laurent Bourg?s <lbourges at openjdk.org>
Date:      2024-08-12 12:09:22 +0000
URL:       https://git.openjdk.org/leyden/commit/89a15f1414f89d2dd32eac791e9155fcb4207e56

8337681: PNGImageWriter uses much more memory than necessary

Reviewed-by: prr, lbourges

! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java
+ test/jdk/javax/imageio/plugins/png/RasterReuseWriteTest.java

Changeset: 61d1dc59
Branch: premain
Author:    Vicente Romero <vromero at openjdk.org>
Date:      2024-08-12 13:52:57 +0000
URL:       https://git.openjdk.org/leyden/commit/61d1dc59535a3dc186bc1986a04efdb4e5a8fa18

8334466: Ambiguous method call with generics may cause FunctionDescriptorLookupError

Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/langtools/tools/javac/lambda/CrashWithFunctionDescriptorLookupErrorTest.java
+ test/langtools/tools/javac/lambda/CrashWithFunctionDescriptorLookupErrorTest.out

Changeset: a36fb368
Branch: premain
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-08-12 15:33:31 +0000
URL:       https://git.openjdk.org/leyden/commit/a36fb368e1a3630d32908884f4abdc3382eb9aaa

8338108: Give better error message in configure if a full XCode is missing

Reviewed-by: jwaters, erikj, shade

! make/autoconf/toolchain.m4

Changeset: 04b146a3
Branch: premain
Author:    SendaoYan <syan at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
Date:      2024-08-12 15:43:40 +0000
URL:       https://git.openjdk.org/leyden/commit/04b146a31f55825e2c8e3c8e42310b3b3337ae95

8337334: Test tools/javac/7142086/T7142086.java timeout with fastdebug binary

Reviewed-by: vromero

! test/langtools/TEST.ROOT
! test/langtools/tools/javac/7142086/T7142086.java

Changeset: f84240bc
Branch: premain
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2024-08-12 16:03:41 +0000
URL:       https://git.openjdk.org/leyden/commit/f84240bca80d2ff01e198bb67931ad4725a5b334

8338011: CDS archived heap object support for 64-bit Windows

Reviewed-by: stuefe, shade, ccheung

! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/utilities/macros.hpp

Changeset: 8d083147
Branch: premain
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2024-08-12 17:15:39 +0000
URL:       https://git.openjdk.org/leyden/commit/8d0831478338e9b084b2c47f46eba9faae3a5eb6

8337795: Type annotation attached to incorrect type during class reading

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java

Changeset: 99edb4a4
Branch: premain
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-08-12 17:20:20 +0000
URL:       https://git.openjdk.org/leyden/commit/99edb4a45d6a4a871dec9c07b41b3ab66b89a4b6

8337702: Use new ForwardExceptionNode to call StubRoutines::forward_exception_entry()

Reviewed-by: thartmann

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/arm/arm.ad
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/riscv/riscv.ad
! src/hotspot/cpu/s390/s390.ad
! src/hotspot/cpu/x86/x86_32.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/adlc/formssel.cpp
! src/hotspot/share/opto/callnode.hpp
! src/hotspot/share/opto/classes.hpp
! src/hotspot/share/opto/domgraph.cpp
! src/hotspot/share/opto/gcm.cpp
! src/hotspot/share/opto/generateOptoStub.cpp
! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/runtime/vmStructs.cpp

Changeset: 2ca136a7
Branch: premain
Author:    Ben Taylor <btaylor at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-12 17:26:51 +0000
URL:       https://git.openjdk.org/leyden/commit/2ca136a7adb6defaea3b7a69d30e6c36bda66e6a

8337815: Relax G1EvacStats atomic operations

Reviewed-by: kbarrett, tschatzl, shade

! src/hotspot/share/gc/g1/g1EvacStats.inline.hpp

Changeset: 41e31d6b
Branch: premain
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-08-12 17:56:46 +0000
URL:       https://git.openjdk.org/leyden/commit/41e31d6b0ae00d70b6fb20c89318fde2bc605edb

8337622: IllegalArgumentException in java.lang.reflect.Field.get

Reviewed-by: dholmes, shade

! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
+ test/hotspot/jtreg/runtime/reflect/ComponentTypeFieldTest.java

Changeset: b93b74e3
Branch: premain
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2024-08-12 19:28:46 +0000
URL:       https://git.openjdk.org/leyden/commit/b93b74e3ebd220e94fb5e33d2ebc62181db97bb0

8338060: jdk/internal/util/ReferencedKeyTest should be more robust

Reviewed-by: never

! test/jdk/jdk/internal/util/ReferencedKeyTest.java

Changeset: 4417c276
Branch: premain
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-08-12 19:43:36 +0000
URL:       https://git.openjdk.org/leyden/commit/4417c276e484c1fe137ed7f4a7c28709d0c99af2

8330535: Update nsk/jdb tests to use driver instead of othervm

Reviewed-by: cjplummer

! test/hotspot/jtreg/vmTestbase/nsk/jdb/caught_exception/caught_exception002/caught_exception002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/classes/classes001/classes001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/classpath/classpath001/classpath001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/clear/clear002/clear002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/clear/clear003/clear003.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/clear/clear004/clear004.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/down/down002/down002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/dump/dump002/dump002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/eval/eval001/eval001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/fields/fields001/fields001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/hidden_class/hc001/hc001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/ignore/ignore001/ignore001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/kill/kill001/kill001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/kill/kill002/kill002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/klass/class001/class001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/list/list002/list002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/list/list003/list003.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/methods/methods002/methods002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/monitor/monitor001/monitor001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/monitor/monitor002/monitor002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/next/next001/next001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/options/connect/connect001/connect001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/options/connect/connect002/connect002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/options/connect/connect003/connect003.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/options/connect/connect004/connect004.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/options/connect/connect005/connect005.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/options/listconnectors/listconnectors001/listconnectors001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/pop/pop001/pop001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/pop_exception/pop_exception001/pop_exception001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/print/print002/print002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/read/read001/read001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/redefine/redefine001/redefine001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/reenter/reenter001/reenter001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/regression/b4689395/b4689395.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/resume/resume002/resume002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/run/run002/run002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/set/set001/set001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/set/set002/set002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/step/step002/step002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/step_up/step_up001/step_up001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/stop_at/stop_at002/stop_at002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/stop_at/stop_at003/stop_at003.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/stop_in/stop_in002/stop_in002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/suspend/suspend001/suspend001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/thread/thread002/thread002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/threadgroup/threadgroup002/threadgroup002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/threadgroups/threadgroups002/threadgroups002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/threads/threads002/threads002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/threads/threads003/threads003.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/trace/trace001/trace001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/uncaught_exception/uncaught_exception002/uncaught_exception002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/unmonitor/unmonitor001/unmonitor001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/untrace/untrace001/untrace001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/unwatch/unwatch001/unwatch001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/unwatch/unwatch002/unwatch002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/up/up002/up002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/use/use001/use001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/watch/watch001/watch001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/watch/watch002/watch002.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/where/where004/where004.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/where/where005/where005.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/where/where006/where006.java
! test/hotspot/jtreg/vmTestbase/nsk/jdb/wherei/wherei001/wherei001.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jdb/JdbTest.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Launcher.java

Changeset: 5079c38d
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-08-12 22:12:01 +0000
URL:       https://git.openjdk.org/leyden/commit/5079c38ddf345b21d8cb1c959bc36c4341e11da6

8338160: Fix -Wzero-as-null-pointer-constant warnings in management.cpp

Reviewed-by: dholmes

! src/hotspot/share/services/management.cpp

Changeset: e70c9bcc
Branch: premain
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2024-08-12 23:00:04 +0000
URL:       https://git.openjdk.org/leyden/commit/e70c9bccaae375be1ee6812dabc9fbaff01a6ab0

8338248: PartialArrayStateAllocator::Impl leaks Arena array

Reviewed-by: kbarrett, shade

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

Changeset: d77e6fe4
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-08-13 05:46:38 +0000
URL:       https://git.openjdk.org/leyden/commit/d77e6fe45c7b834db457a772ce0bea514d2e44f3

8338154: Fix -Wzero-as-null-pointer-constant warnings in gtest framework

Reviewed-by: ihse, dholmes, jwaters

! make/hotspot/lib/CompileGtest.gmk
! test/hotspot/gtest/gtestMain.cpp

Changeset: 73ddb7de
Branch: premain
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-08-13 05:52:44 +0000
URL:       https://git.openjdk.org/leyden/commit/73ddb7deab26c526337ec6e7cd5f528f698a552c

8335628: C2 SuperWord: cleanup: remove SuperWord::longer_type_for_conversion

Reviewed-by: chagedorn, kvn

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

Changeset: c27a8c8c
Branch: premain
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-08-13 05:52:58 +0000
URL:       https://git.openjdk.org/leyden/commit/c27a8c8c8b867e6812b905f6154762802a498dbd

8338124: C2 SuperWord: MulAddS2I input permutation still partially broken after JDK-8333840

Reviewed-by: chagedorn, thartmann, kvn

! src/hotspot/share/opto/superword.cpp
! test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java

Changeset: 73f7a5f1
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-08-13 07:27:49 +0000
URL:       https://git.openjdk.org/leyden/commit/73f7a5f15dbba54a98f3916ff1190520ac07874d

8338155: Fix -Wzero-as-null-pointer-constant warnings involving PTHREAD_MUTEX_INITIALIZER

Reviewed-by: dholmes, dlong

! src/hotspot/os/linux/os_perf_linux.cpp
! src/hotspot/os/posix/threadCritical_posix.cpp
! src/hotspot/share/utilities/compilerWarnings.hpp
! src/hotspot/share/utilities/compilerWarnings_gcc.hpp

Changeset: 5bf27098
Branch: premain
Author:    Saint Wesonga <saint.wesonga at microsoft.com>
Committer: Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2024-08-13 08:10:29 +0000
URL:       https://git.openjdk.org/leyden/commit/5bf27098e22172ed5d3ec0c43fe0553f8322c4b1

8334475: UnsafeIntrinsicsTest.java#ZGenerationalDebug assert(!assert_on_failure) failed: Has low-order bits set

Reviewed-by: stefank, eosterlund, aboldtch

! src/hotspot/os_cpu/windows_aarch64/copy_windows_aarch64.hpp

Changeset: ba69ed7c
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-13 08:11:47 +0000
URL:       https://git.openjdk.org/leyden/commit/ba69ed7c58fcf99ed18dfd8840125ddcac9460bb

8338202: Shenandoah: Improve handshake closure labels

Reviewed-by: rkennke, ysr, wkemper

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp

Changeset: fbe4cc96
Branch: premain
Author:    Viktor Klang <vklang at openjdk.org>
Date:      2024-08-13 09:51:08 +0000
URL:       https://git.openjdk.org/leyden/commit/fbe4cc96e223882a18c7ff666fe6f68b3fa2cfe4

8336384: AbstractQueuedSynchronizer.acquire should cancel acquire when failing due to a LinkageError or other errors

Reviewed-by: alanb

! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java

Changeset: ff8a9f92
Branch: premain
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-08-13 11:48:50 +0000
URL:       https://git.openjdk.org/leyden/commit/ff8a9f9267c480fe0be8470cda870fd77763fb31

8337318: Deoptimization::relock_objects fails assert(monitor->owner() == Thread::current()) failed: must be

Co-authored-by: Richard Reingruber <rrich at openjdk.org>
Reviewed-by: rrich, dholmes, shade, pchilanomate

! src/hotspot/share/runtime/synchronizer.cpp
! test/jdk/com/sun/jdi/EATests.java

Changeset: 76e33b6c
Branch: premain
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2024-08-13 13:13:14 +0000
URL:       https://git.openjdk.org/leyden/commit/76e33b6c1517599e14ee34371c945aafcd752e4e

8336148: Test runtime/locking/TestRecursiveMonitorChurn.java failed: Unexpected Inflation

Reviewed-by: dholmes, eosterlund

! test/hotspot/jtreg/runtime/locking/TestRecursiveMonitorChurn.java

Changeset: 877fd5a7
Branch: premain
Author:    Casper Norrbin <casper.norrbin at oracle.com>
Committer: Julian Waters <jwaters at openjdk.org>
Date:      2024-08-13 14:43:44 +0000
URL:       https://git.openjdk.org/leyden/commit/877fd5a768647790d0a43aaca247043bae70d708

8337595: Remove empty statements in src/hotspot/share/memory/metaspace

Reviewed-by: stefank, dholmes, jwaters

! src/hotspot/share/memory/metaspace/metaspaceCommon.hpp

Changeset: 9e282e5c
Branch: premain
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2024-08-13 15:05:49 +0000
URL:       https://git.openjdk.org/leyden/commit/9e282e5c966a9c065de8b901b7d30bb5c9ccf243

8337998: CompletionFailure in getEnclosingType attaching type annotations

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/langtools/tools/javac/annotations/typeAnnotations/CompletionErrorOnEnclosingType.java
! test/langtools/tools/javac/diags/examples.not-yet.txt

Changeset: 6af1d6ff
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-08-13 15:14:06 +0000
URL:       https://git.openjdk.org/leyden/commit/6af1d6ff210b3ddbc7d1585428b49631248a500b

8335927: Revisit AnnotationConstantValueEntry and AnnotationValue.OfConstant

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
! src/java.base/share/classes/java/lang/classfile/constantpool/AnnotationConstantValueEntry.java
! src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java
! test/jdk/jdk/classfile/AnnotationTest.java
! test/jdk/jdk/classfile/ClassPrinterTest.java
! test/jdk/jdk/classfile/helpers/RebuildingTransformation.java
! test/langtools/tools/javac/annotations/typeAnnotations/classfile/AnonymousClassTest.java
! test/langtools/tools/javac/classfiles/attributes/AnnotationDefault/AnnotationDefaultVerifier.java
! test/langtools/tools/javac/classfiles/attributes/annotations/TestAnnotationInfo.java

Changeset: 58b95705
Branch: premain
Author:    Alan Bateman <alanb at openjdk.org>
Date:      2024-08-13 16:05:38 +0000
URL:       https://git.openjdk.org/leyden/commit/58b957054437edee7d0abc365133985ac30a6af4

8338142: (dc) DatagramChannelImpl.blockingReceive can use untimed-park when no timeout set

Reviewed-by: dfuchs

! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java

Changeset: 21ca91e5
Branch: premain
Author:    Afshin Zafari <azafari at openjdk.org>
Date:      2024-08-13 16:25:43 +0000
URL:       https://git.openjdk.org/leyden/commit/21ca91e55dd83dc011e67a2d056e3e3bd44d40b5

8300800: UB: Shift exponent 32 is too large for 32-bit type 'int'

Reviewed-by: kbarrett, adinn, gziemski

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

Changeset: 84c3065e
Branch: premain
Author:    Neethu Prasad <nprasad at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-13 17:22:41 +0000
URL:       https://git.openjdk.org/leyden/commit/84c3065e8004122f3455a8c28c8719b2c8111c17

8335865: Shenandoah: Improve THP pretouch after JDK-8315923

Reviewed-by: shade, wkemper

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

Changeset: ca99f37f
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-08-13 18:02:24 +0000
URL:       https://git.openjdk.org/leyden/commit/ca99f37f82bf59fc720babbc155502ef92d34de6

8338156: Fix -Wzero-as-null-pointer-constant warnings in jvmciCompilerToVM.cpp

Reviewed-by: tschatzl, jwaters, dnsimon

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

Changeset: 8e682aca
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-08-13 18:03:52 +0000
URL:       https://git.openjdk.org/leyden/commit/8e682aca24fba0803dceef513957fb2122895b87

8338158: Cleanup ShouldNotXXX uses in machnode.cpp

Reviewed-by: chagedorn, kvn, dlong

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

Changeset: 90527a57
Branch: premain
Author:    Neethu Prasad <nprasad at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-13 19:56:07 +0000
URL:       https://git.openjdk.org/leyden/commit/90527a57848f452be3be089a703cbc2af2d1657a

8336742: Shenandoah: Add more verbose logging/stats for mark termination attempts

Reviewed-by: shade, wkemper, rkennke

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp

Changeset: 5ca207db
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-13 15:11:51 +0000
URL:       https://git.openjdk.org/leyden/commit/5ca207db2d324f1c797ab82396ec913f0a2ee9a4

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

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
! src/hotspot/cpu/s390/stubGenerator_s390.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/runtime_x86_64.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/asm/codeBuffer.cpp
! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/ci/ciReplay.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/classfile/moduleEntry.cpp
! src/hotspot/share/classfile/symbolTable.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/codeCache.hpp
! src/hotspot/share/code/dependencies.cpp
! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/compiler/compilerOracle.cpp
! src/hotspot/share/include/jvm.h
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/memory/allocation.cpp
! src/hotspot/share/memory/allocation.hpp
! src/hotspot/share/memory/virtualspace.cpp
! src/hotspot/share/oops/constantPool.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/output.cpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/runtime.cpp
! src/hotspot/share/opto/runtime.hpp
! src/hotspot/share/opto/vectorIntrinsics.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/jvmtiExport.cpp
! src/hotspot/share/prims/jvmtiExport.hpp
! src/hotspot/share/prims/methodHandles.cpp
! src/hotspot/share/prims/perf.cpp
! src/hotspot/share/prims/unsafe.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/flags/jvmFlag.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/perfData.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/sharedRuntime.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/invoke/LambdaForm.java
! test/hotspot/jtreg/ProblemList.txt
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
! src/hotspot/cpu/s390/stubGenerator_s390.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/runtime_x86_64.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/asm/codeBuffer.cpp
! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/ci/ciReplay.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/classfile/moduleEntry.cpp
! src/hotspot/share/classfile/symbolTable.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
+ src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/codeCache.hpp
! src/hotspot/share/code/dependencies.cpp
! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/compiler/compilerOracle.cpp
! src/hotspot/share/include/jvm.h
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/memory/allocation.cpp
! src/hotspot/share/memory/allocation.hpp
! src/hotspot/share/memory/virtualspace.cpp
! src/hotspot/share/oops/constantPool.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/output.cpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/runtime.cpp
! src/hotspot/share/opto/runtime.hpp
! src/hotspot/share/opto/vectorIntrinsics.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/jvmtiExport.cpp
! src/hotspot/share/prims/jvmtiExport.hpp
! src/hotspot/share/prims/methodHandles.cpp
! src/hotspot/share/prims/perf.cpp
! src/hotspot/share/prims/unsafe.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/flags/jvmFlag.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/perfData.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/sharedRuntime.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/invoke/LambdaForm.java
! test/hotspot/jtreg/ProblemList.txt


From duke at openjdk.org  Wed Aug 14 14:14:40 2024
From: duke at openjdk.org (duke)
Date: Wed, 14 Aug 2024 14:14:40 GMT
Subject: git: openjdk/leyden: premain: 2 new changesets
Message-ID: <41487471-72db-4f13-a8d5-35765a5e0ef7@openjdk.org>

Changeset: b065ce74
Branch: premain
Author:    Ashutosh Mehra <asmehra at redhat.com>
Date:      2024-08-14 09:57:42 +0000
URL:       https://git.openjdk.org/leyden/commit/b065ce740cb227afedb8b28941d75f3caf97767a

Set _sc_count correctly when only one of c1 compiler or c2 compiler is enabled

Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changeset: e4059458
Branch: premain
Author:    Ashutosh Mehra <asmehra at redhat.com>
Date:      2024-08-14 09:59:20 +0000
URL:       https://git.openjdk.org/leyden/commit/e4059458293c43119adb61520ad7c15abc17ca24

Enable finding scc entry when _sc_count is 0 (using -XX:-UseCodeLoadThread)

Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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


From asmehra at redhat.com  Wed Aug 14 19:19:30 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Wed, 14 Aug 2024 15:19:30 -0400
Subject: [External] : Re: premain: Possible solutions to use runtime G1
 region grain size in AOT code (JDK-8335440)
In-Reply-To: <594256c5-b81d-453d-a4f4-6165b8368a9e@oracle.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>
 <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>
 <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>
 <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>
 <84057040-3d3a-48be-88b3-502205ee6a7d@oracle.com>
 <a231c010-9fbc-485c-8e6e-6e8040524889@redhat.com>
 <b2f3983a-d6fa-4a07-a742-9e0c4a59e88d@oracle.com>
 <5e931bd6-c766-4939-b338-c60594b5e665@redhat.com>
 <5257f86c-2910-45c3-972f-929494fb3267@oracle.com>
 <3db5a5f3-41c3-4cfa-b446-273af5625ac1@redhat.com>
 <594256c5-b81d-453d-a4f4-6165b8368a9e@oracle.com>
Message-ID: <CAKt0pyTjmXhXhk9snL3-D-qJo_S_H5c0A6HyxPkYcBSXR7jbLw@mail.gmail.com>

Hi Vladimir,

I have done a port of Andrew D's patch for version 4 of the solution to
x8-64.
Here is the link to the change sets on top of Andrew's original patch for
v4.
https://github.com/openjdk/leyden/compare/premain...ashu-mehra:leyden:JDK-8335440-load-via-codecache?expand=1

Can you please review the patch? Any feedback is appreciated.

Few things worth calling out:
1. As Andrew D mentioned in his previous mail, C2 coalesces a pointer
constant load followed by an add to an updated
pointer constant load. And because C2 on x86 generates external_word reloc
for every constant pointer loaded,
it means we would have to add every address in AOTRuntimeConstants range to
the SCAddressTable,
To avoid this, I used the same mechanism as aarch64 to identify the
AOTRuntimeConstants addresses in the back-end.

2. C1 doesn't support use of 3-operand shift instruction (sarx/shlx/shrx).
I extended C1 to lower shift ops using these instructions if possible. Does
this make sense?

3. In G1BarrierSetAssembler::g1_write_barrier_post() the tmp2 register is
not available for use.
The caller G1BarrierSetAssembler::oop_store_at uses tmp2 for storing
uncompressed oop.
Also, rscratch2 is not available as it is passed as tmp1 which is also in
use.
So we don't really have any free registers left.
In my patch I resorted to using rscratch1. Is there a need to spill that
register to stack before using it?

Thanks,
- Ashutosh Mehra


On Wed, Jul 31, 2024 at 4:08?PM Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

> Very nice. I like it.
>
> Thanks,
> Vladimir K
>
> On 7/31/24 8:23 AM, Andrew Dinn wrote:
> > I now have a fourth solution to the region resizing problem which I
> think is probably the nicest looking one so far:
> >
> >
> >
> https://urldefense.com/v3/__https://github.com/adinn/leyden/compare/premain...adinn:leyden:JDK-8335440-load-via-codecache?expand=1__;!!ACWV5N9M2RV99hQ!JI8n2MMyF844NBqR63MhWXggKzPCoouZ8pcwgasAa94iYPRzpcD7af-zSicg5Wm0nv9ZyaF1CpaC74Mqn3g$
> > Opinions welcome!
> >
> > This version relies on a code cache AOT data area, generated into the
> initial stubs blob, which stores runtime constants
> > that parameterize operation of AOT code. The AOT data area is
> initialized with the current runtime constants immediately
> > after universe init. AOT code loads the constants indirectly via the
> region base address rather than embedding them into
> > instructions. Non-AOT code can continue to use these constants as
> immediate values.
> >
> > With this patch I have included the region grain size shift and the card
> table shift in the data area. So, this patch
> > ensures that AOT code loads both grain shift and card shift counts
> rather than using immediates. I tested it passing
> > -XX:GCCardSizeInBytes=128 -Xmx4M to a production run and it works fine.
> >
> > The only address that needs relocating wit this patch is the AOT data
> area base. Note that it was useful using this to
> > implement loading of two AOT code parameters as it highlights a general
> problem that is not face with only one field.
> >
> > I decide to register only the base address of the AOT data area with the
> code cache as a relocatable (external) address
> > because this is more robust than requiring registration of the address
> of every data field embedded in the AOT data
> > area. However, in order for the AOT cache to be able to relocate loads
> from the data area they need to be implemented by
> > installing the base address in a register and then adding the offset
> before executing the load.
> >
> > This is fine for stub code where the generator can simply plant a load
> effective address (lea) of a pointer constant
> > into a register and then add in the offset. However, I know C2 Value
> optimizations will certainly coalesce a pointer
> > constant load followed by an add to an updated pointer constant load. I
> think this can also happen with C1 (it doesn't
> > at the moment because in the current C1 code the grain shift load -- at
> offset 0 -- happens inline, while the card shift
> > load -- at offset 4 -- only happens in a callout to stub code). I fixed
> this general problem by ensuring that the C1 and
> > C2 back ends detect pointer constants that lie anywhere in the data area
> address *range*. For (only) those cases the lea
> > is implemenetd by generating a base address load plus offset add.
> >
> > It would be nice to be ale to fold the offset into the subsequent load.
> I'll look into that as a follow-up. Either way,
> > I think this looks like the simplest and most robust solution to
> ensuring that AOT code is correctly parameterized at
> > runtime. It is particularly nice that it doesn't need any new
> relocations.
> >
> > regards,
> >
> >
> > Andrew Dinn
> > -----------
> >
> > On 24/07/2024 20:43, Vladimir Kozlov wrote:
> >> Thank you for checking code for card_table_address.
> >>
> >>  > Oh, that's a nuisance. I was concerned that I was perhaps using the
> wrong reloc model here. Should I be encoding info
> >>  > about what/how to patch the target instruction(s) using reloc data?
> >>
> >> I am currently thinking about adding indication what relocation is
> pointing on: blob, stubs, external address, string.
> >> Currently we are looking through all our address tables in SCCache to
> find match. Would be nice if we can get this
> >> information from relocation. And I also thought about using format for
> it but realized it is PD and it reserves bits
> >> in RelocInfo word. On other hand we can add an other 12 (31 - 18 - 1)
> new relocations without using additional bits.
> >>
> >> In short add new relocation if you need it.
> >>
> >> Thanks,
> >> Vladimir K
> >>
> >> On 7/24/24 7:40 AM, Andrew Dinn wrote:
> >>> On 23/07/2024 18:44, Vladimir Kozlov wrote:
> >>>> I agree. As we discussed on meeting we may use it to patch compressed
> oops/klass code too.
> >>>
> >>> Yes, we could potentially do something similar to adjust the shift and
> base adjustment employed when generating a
> >>> narrow oop or klass encode or decode. However, that would only be
> useful with certain limits.
> >>>
> >>> 1) We can only cater for a change from one narrow-oop/klass base+shift
> configuration to another base+shift
> >>> configuration. Patching code to switch from narrow oops/klass pointers
> to full width (or vice versa) would require
> >>> adjusting not just the oop/klass load/store but also other
> instructions that hard-wire header/payload field sizes and
> >>> offsets based on the narrow/full width layout assumptions. Likewise it
> would require resizing and repacking objects
> >>> stored in the CDS mapped heap section.
> >>>
> >>> 2) Even if we restrict ourselves to the case where we retain narrow
> oops and simply allow for a change of base and/or
> >>> shift (i.e. keep the object layouts the same), that will only work if
> pointers installed in mapped CDS heap objects
> >>> are also rewritten to use the runtime encoding.
> >>>
> >>> 3) When generating AOT code for the encode and decode we would have to
> allow for the worst case i.e. leave room
> >>> (nops) for both heap-base adjustment and shift even when they are not
> needed at generate time.
> >>>
> >>>> We have the same issue with card_table_address. I actually don't know
> why current AOT code works??? May be because
> >>>> it is the same value in training and production runs. But we need to
> fix it too.
> >>>
> >>>> It is constant node which is embedded into AddP node:
> >>>>
> https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp*L96__;Iw!!ACWV5N9M2RV99hQ!LjgTGnmqk1Ez4pzqXuTXAbZZfHhhP9a1zAFdWGz7V59xO3ggQYVrdW3jTlSNYML_SvRN0Ip_HA-9E0w0Jbo$
> >>>
> >>> I believe C2 is ok. On AArch64 the C2 back end has an operand called
> immByteMapBase that matches any use of
> >>> byte_map_base as a pointer constant. A corresponding rule ensures that
> any attempt to load that constant pointer is
> >>> done by calling
> >>>
> >>>    __ load_byte_map_base()
> >>>
> >>> and the macr assembler uses an ExternalAddress when StoreCachedCode is
> set.
> >>>
> >>>> I marked it only in platform specific code:
> >>>>
> https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/premain/src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp*L68__;Iw!!ACWV5N9M2RV99hQ!LjgTGnmqk1Ez4pzqXuTXAbZZfHhhP9a1zAFdWGz7V59xO3ggQYVrdW3jTlSNYML_SvRN0Ip_HA-92hI_Afg$
> >>>
> >>> I also think there is no mystery as to why this works on AArch64. The
> equivalent code in
> >>> cardTableBarrierSetAssembler_aarch64.cpp also calls
> >>>
> >>>    __ load_byte_map_base()
> >>>
> >>> However, that said, looking at the barrier card table write it seems
> the card table shift is another value that the
> >>> user might decide to reconfigure between assembly and production runs.
> The shift is derived form GCCardTableSize
> >>> which is a gc global command line option so susceptible to being reset.
> >>>
> >>> We could use an aot_reloc with a different format to tag card table
> shift lsr instructions and patch them at shared
> >>> code load to use the current runtime GCCardTableSize. Of course, this
> is not as urgent a problem as the grain size
> >>> shift because the card table size only ever changes thanks to an
> explicit command line request whereas the grain size
> >>> may be changed ergonomically when -Xmx is passed.
> >>>
> >>>> Be careful with using `format()` in shared code because it depends on
> platform specific setting `format_width` in
> >>>> `relocInfo_<arch>.hpp` (32-bit arm has format_width = 0).
> >>>
> >>> Oh, that's a nuisance. I was concerned that I was perhaps using the
> wrong reloc model here. Should I be encoding info
> >>> about what/how to patch the target instruction(s) using reloc data?
> >>>
> >>> regards,
> >>>
> >>>
> >>> Andrew Dinn
> >>> -----------
> >>>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240814/a605ba06/attachment.htm>

From vladimir.kozlov at oracle.com  Wed Aug 14 23:50:16 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 14 Aug 2024 16:50:16 -0700
Subject: [External] : Re: premain: Possible solutions to use runtime G1
 region grain size in AOT code (JDK-8335440)
In-Reply-To: <CAKt0pyTjmXhXhk9snL3-D-qJo_S_H5c0A6HyxPkYcBSXR7jbLw@mail.gmail.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>
 <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>
 <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>
 <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>
 <84057040-3d3a-48be-88b3-502205ee6a7d@oracle.com>
 <a231c010-9fbc-485c-8e6e-6e8040524889@redhat.com>
 <b2f3983a-d6fa-4a07-a742-9e0c4a59e88d@oracle.com>
 <5e931bd6-c766-4939-b338-c60594b5e665@redhat.com>
 <5257f86c-2910-45c3-972f-929494fb3267@oracle.com>
 <3db5a5f3-41c3-4cfa-b446-273af5625ac1@redhat.com>
 <594256c5-b81d-453d-a4f4-6165b8368a9e@oracle.com>
 <CAKt0pyTjmXhXhk9snL3-D-qJo_S_H5c0A6HyxPkYcBSXR7jbLw@mail.gmail.com>
Message-ID: <fdad55a9-50af-42c8-8a6a-f9f91a1a72f6@oracle.com>

Do we really need AOTRuntimeConstants instance be a stub in CodeCache?
Looking on this code and I think this complicate implementation if use 
ExternalAddress relocation anyway. Can it be static instance in 
SCCache.cpp which we initialize the same way as in current changes?

I do not understand why you have concern about having separate 
relocation for each constant in AOTRuntimeConstants. We have only 2 now. 
Even they grow I don't think we will have a lot of them. Actually the 
question: will it simplify code if each constant's address is treated as 
separate and not offset in AOTRuntimeConstants? Instead of loading 
AOTRuntimeConstants address and then adding offset we just load address 
of constant.

I don't understand question about C1 (I am not familiar with it). What 
it generates for shifts now? Why you need 3-operand shift?

Code style: I noticed and aarch64.ad still using old stile of 
instructions definition using `enc_class`. We don't do this any more (at 
least in x86*.ad) when we adding new instructions with one 
implementation. Please use `ins_encode %{ %}` in such cases.

I think, if you need additional register you should push/pop to 
guarantee we don't stomp over some used value.

Thanks,
Vladimir

On 8/14/24 12:19 PM, Ashutosh Mehra wrote:
> Hi Vladimir,
> 
> I have done a port of Andrew D's patch for version 4 of the solution to 
> x8-64.
> Here is the link to the change sets on top of Andrew's original 
> patch?for v4.
> https://github.com/openjdk/leyden/compare/premain...ashu-mehra:leyden:JDK-8335440-load-via-codecache?expand=1 <https://urldefense.com/v3/__https://github.com/openjdk/leyden/compare/premain...ashu-mehra:leyden:JDK-8335440-load-via-codecache?expand=1__;!!ACWV5N9M2RV99hQ!MMdG9tP3z_X4-DsBZBIi5944rqlHAPv9JkmNuc2W8V0r_lUjDKz7AVe15KyfC3C92KLfpIoSzNFXM103WlW7jg$>
> 
> Can you please review?the patch? Any feedback is appreciated.
> 
> Few things worth calling out:
> 1. As Andrew D mentioned in his previous mail, C2 coalesces a pointer 
> constant load followed by an add to an updated
> pointer constant load. And because C2 on x86 generates external_word 
> reloc for every constant pointer loaded,
> it means we would have to add every address in AOTRuntimeConstants range 
> to the SCAddressTable,
> To avoid this, I used the same mechanism as aarch64 to identify the 
> AOTRuntimeConstants addresses in the back-end.
> 
> 2. C1 doesn't support use of 3-operand shift instruction (sarx/shlx/shrx).
> I extended C1 to lower shift ops?using these instructions if possible. 
> Does this?make sense?
> 
> 3. In?G1BarrierSetAssembler::g1_write_barrier_post() the tmp2 register 
> is not available for use.
> The?caller?G1BarrierSetAssembler::oop_store_at uses tmp2 for storing 
> uncompressed oop.
> Also, rscratch2 is not available as it is passed as tmp1 which is also 
> in use.
> So we don't really have any free registers left.
> In my patch I resorted to using rscratch1. Is there a need to spill that 
> register to stack before using it?
> 
> Thanks,
> - Ashutosh Mehra
> 
> 
> On Wed, Jul 31, 2024 at 4:08?PM Vladimir Kozlov 
> <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
> 
>     Very nice. I like it.
> 
>     Thanks,
>     Vladimir K
> 
>     On 7/31/24 8:23 AM, Andrew Dinn wrote:
>      > I now have a fourth solution to the region resizing problem which
>     I think is probably the nicest looking one so far:
>      >
>      >
>      >
>     https://urldefense.com/v3/__https://github.com/adinn/leyden/compare/premain...adinn:leyden:JDK-8335440-load-via-codecache?expand=1__;!!ACWV5N9M2RV99hQ!JI8n2MMyF844NBqR63MhWXggKzPCoouZ8pcwgasAa94iYPRzpcD7af-zSicg5Wm0nv9ZyaF1CpaC74Mqn3g$ <https://urldefense.com/v3/__https://github.com/adinn/leyden/compare/premain...adinn:leyden:JDK-8335440-load-via-codecache?expand=1__;!!ACWV5N9M2RV99hQ!JI8n2MMyF844NBqR63MhWXggKzPCoouZ8pcwgasAa94iYPRzpcD7af-zSicg5Wm0nv9ZyaF1CpaC74Mqn3g$>
>      > Opinions welcome!
>      >
>      > This version relies on a code cache AOT data area, generated into
>     the initial stubs blob, which stores runtime constants
>      > that parameterize operation of AOT code. The AOT data area is
>     initialized with the current runtime constants immediately
>      > after universe init. AOT code loads the constants indirectly via
>     the region base address rather than embedding them into
>      > instructions. Non-AOT code can continue to use these constants as
>     immediate values.
>      >
>      > With this patch I have included the region grain size shift and
>     the card table shift in the data area. So, this patch
>      > ensures that AOT code loads both grain shift and card shift
>     counts rather than using immediates. I tested it passing
>      > -XX:GCCardSizeInBytes=128 -Xmx4M to a production run and it works
>     fine.
>      >
>      > The only address that needs relocating wit this patch is the AOT
>     data area base. Note that it was useful using this to
>      > implement loading of two AOT code parameters as it highlights a
>     general problem that is not face with only one field.
>      >
>      > I decide to register only the base address of the AOT data area
>     with the code cache as a relocatable (external) address
>      > because this is more robust than requiring registration of the
>     address of every data field embedded in the AOT data
>      > area. However, in order for the AOT cache to be able to relocate
>     loads from the data area they need to be implemented by
>      > installing the base address in a register and then adding the
>     offset before executing the load.
>      >
>      > This is fine for stub code where the generator can simply plant a
>     load effective address (lea) of a pointer constant
>      > into a register and then add in the offset. However, I know C2
>     Value optimizations will certainly coalesce a pointer
>      > constant load followed by an add to an updated pointer constant
>     load. I think this can also happen with C1 (it doesn't
>      > at the moment because in the current C1 code the grain shift load
>     -- at offset 0 -- happens inline, while the card shift
>      > load -- at offset 4 -- only happens in a callout to stub code). I
>     fixed this general problem by ensuring that the C1 and
>      > C2 back ends detect pointer constants that lie anywhere in the
>     data area address *range*. For (only) those cases the lea
>      > is implemenetd by generating a base address load plus offset add.
>      >
>      > It would be nice to be ale to fold the offset into the subsequent
>     load. I'll look into that as a follow-up. Either way,
>      > I think this looks like the simplest and most robust solution to
>     ensuring that AOT code is correctly parameterized at
>      > runtime. It is particularly nice that it doesn't need any new
>     relocations.
>      >
>      > regards,
>      >
>      >
>      > Andrew Dinn
>      > -----------
>      >
>      > On 24/07/2024 20:43, Vladimir Kozlov wrote:
>      >> Thank you for checking code for card_table_address.
>      >>
>      >> ?> Oh, that's a nuisance. I was concerned that I was perhaps
>     using the wrong reloc model here. Should I be encoding info
>      >> ?> about what/how to patch the target instruction(s) using reloc
>     data?
>      >>
>      >> I am currently thinking about adding indication what relocation
>     is pointing on: blob, stubs, external address, string.
>      >> Currently we are looking through all our address tables in
>     SCCache to find match. Would be nice if we can get this
>      >> information from relocation. And I also thought about using
>     format for it but realized it is PD and it reserves bits
>      >> in RelocInfo word. On other hand we can add an other 12 (31 - 18
>     - 1) new relocations without using additional bits.
>      >>
>      >> In short add new relocation if you need it.
>      >>
>      >> Thanks,
>      >> Vladimir K
>      >>
>      >> On 7/24/24 7:40 AM, Andrew Dinn wrote:
>      >>> On 23/07/2024 18:44, Vladimir Kozlov wrote:
>      >>>> I agree. As we discussed on meeting we may use it to patch
>     compressed oops/klass code too.
>      >>>
>      >>> Yes, we could potentially do something similar to adjust the
>     shift and base adjustment employed when generating a
>      >>> narrow oop or klass encode or decode. However, that would only
>     be useful with certain limits.
>      >>>
>      >>> 1) We can only cater for a change from one narrow-oop/klass
>     base+shift configuration to another base+shift
>      >>> configuration. Patching code to switch from narrow oops/klass
>     pointers to full width (or vice versa) would require
>      >>> adjusting not just the oop/klass load/store but also other
>     instructions that hard-wire header/payload field sizes and
>      >>> offsets based on the narrow/full width layout assumptions.
>     Likewise it would require resizing and repacking objects
>      >>> stored in the CDS mapped heap section.
>      >>>
>      >>> 2) Even if we restrict ourselves to the case where we retain
>     narrow oops and simply allow for a change of base and/or
>      >>> shift (i.e. keep the object layouts the same), that will only
>     work if pointers installed in mapped CDS heap objects
>      >>> are also rewritten to use the runtime encoding.
>      >>>
>      >>> 3) When generating AOT code for the encode and decode we would
>     have to allow for the worst case i.e. leave room
>      >>> (nops) for both heap-base adjustment and shift even when they
>     are not needed at generate time.
>      >>>
>      >>>> We have the same issue with card_table_address. I actually
>     don't know why current AOT code works??? May be because
>      >>>> it is the same value in training and production runs. But we
>     need to fix it too.
>      >>>
>      >>>> It is constant node which is embedded into AddP node:
>      >>>>
>     https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp*L96__;Iw!!ACWV5N9M2RV99hQ!LjgTGnmqk1Ez4pzqXuTXAbZZfHhhP9a1zAFdWGz7V59xO3ggQYVrdW3jTlSNYML_SvRN0Ip_HA-9E0w0Jbo$ <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp*L96__;Iw!!ACWV5N9M2RV99hQ!LjgTGnmqk1Ez4pzqXuTXAbZZfHhhP9a1zAFdWGz7V59xO3ggQYVrdW3jTlSNYML_SvRN0Ip_HA-9E0w0Jbo$>
>      >>>
>      >>> I believe C2 is ok. On AArch64 the C2 back end has an operand
>     called immByteMapBase that matches any use of
>      >>> byte_map_base as a pointer constant. A corresponding rule
>     ensures that any attempt to load that constant pointer is
>      >>> done by calling
>      >>>
>      >>> ?? __ load_byte_map_base()
>      >>>
>      >>> and the macr assembler uses an ExternalAddress when
>     StoreCachedCode is set.
>      >>>
>      >>>> I marked it only in platform specific code:
>      >>>>
>     https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/premain/src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp*L68__;Iw!!ACWV5N9M2RV99hQ!LjgTGnmqk1Ez4pzqXuTXAbZZfHhhP9a1zAFdWGz7V59xO3ggQYVrdW3jTlSNYML_SvRN0Ip_HA-92hI_Afg$ <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/premain/src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp*L68__;Iw!!ACWV5N9M2RV99hQ!LjgTGnmqk1Ez4pzqXuTXAbZZfHhhP9a1zAFdWGz7V59xO3ggQYVrdW3jTlSNYML_SvRN0Ip_HA-92hI_Afg$>
>      >>>
>      >>> I also think there is no mystery as to why this works on
>     AArch64. The equivalent code in
>      >>> cardTableBarrierSetAssembler_aarch64.cpp also calls
>      >>>
>      >>> ?? __ load_byte_map_base()
>      >>>
>      >>> However, that said, looking at the barrier card table write it
>     seems the card table shift is another value that the
>      >>> user might decide to reconfigure between assembly and
>     production runs. The shift is derived form GCCardTableSize
>      >>> which is a gc global command line option so susceptible to
>     being reset.
>      >>>
>      >>> We could use an aot_reloc with a different format to tag card
>     table shift lsr instructions and patch them at shared
>      >>> code load to use the current runtime GCCardTableSize. Of
>     course, this is not as urgent a problem as the grain size
>      >>> shift because the card table size only ever changes thanks to
>     an explicit command line request whereas the grain size
>      >>> may be changed ergonomically when -Xmx is passed.
>      >>>
>      >>>> Be careful with using `format()` in shared code because it
>     depends on platform specific setting `format_width` in
>      >>>> `relocInfo_<arch>.hpp` (32-bit arm has format_width = 0).
>      >>>
>      >>> Oh, that's a nuisance. I was concerned that I was perhaps using
>     the wrong reloc model here. Should I be encoding info
>      >>> about what/how to patch the target instruction(s) using reloc data?
>      >>>
>      >>> regards,
>      >>>
>      >>>
>      >>> Andrew Dinn
>      >>> -----------
>      >>>
>      >>
>      >
> 

From adinn at redhat.com  Thu Aug 15 10:18:06 2024
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 15 Aug 2024 11:18:06 +0100
Subject: [External] : Re: premain: Possible solutions to use runtime G1
 region grain size in AOT code (JDK-8335440)
In-Reply-To: <fdad55a9-50af-42c8-8a6a-f9f91a1a72f6@oracle.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>
 <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>
 <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>
 <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>
 <84057040-3d3a-48be-88b3-502205ee6a7d@oracle.com>
 <a231c010-9fbc-485c-8e6e-6e8040524889@redhat.com>
 <b2f3983a-d6fa-4a07-a742-9e0c4a59e88d@oracle.com>
 <5e931bd6-c766-4939-b338-c60594b5e665@redhat.com>
 <5257f86c-2910-45c3-972f-929494fb3267@oracle.com>
 <3db5a5f3-41c3-4cfa-b446-273af5625ac1@redhat.com>
 <594256c5-b81d-453d-a4f4-6165b8368a9e@oracle.com>
 <CAKt0pyTjmXhXhk9snL3-D-qJo_S_H5c0A6HyxPkYcBSXR7jbLw@mail.gmail.com>
 <fdad55a9-50af-42c8-8a6a-f9f91a1a72f6@oracle.com>
Message-ID: <17da0ba4-1934-4f4f-804e-2a4ba6cef45e@redhat.com>

On 15/08/2024 00:50, Vladimir Kozlov wrote:
> Do we really need AOTRuntimeConstants instance be a stub in CodeCache?
> Looking on this code and I think this complicate implementation if use 
> ExternalAddress relocation anyway. Can it be static instance in 
> SCCache.cpp which we initialize the same way as in current changes?

Yes, you are right: we don't need the AOTRuntimeConstants struct to be 
embedded in the cache if we are using an ExternalRelocation. The initial 
idea for doing that was because it provides a 32-bit bound on the offset 
from any struct field to a corresponding field load (lea). That would 
allow us to use PC-relative loads of the field addresses -- which saves 
instruction footprint on AArch64, possibly also on x86? However, we can 
only do that if we also implement a new relocation (which seems 
unnecessary).

So, we will redefine the AOTRuntimeConstants struct as a C++ static field.

> I do not understand why you have concern about having separate 
> relocation for each constant in AOTRuntimeConstants. We have only 2 now. 
> Even they grow I don't think we will have a lot of them. Actually the 
> question: will it simplify code if each constant's address is treated as 
> separate and not offset in AOTRuntimeConstants? Instead of loading 
> AOTRuntimeConstants address and then adding offset we just load address 
> of constant.

Yes, you are right again: if we register the address of every field in 
the struct in the SCC address table then that will simplify the back end 
code. I was not sure how much we wanted to rely on address table 
registration but given that we *are* reliant on it just now then we 
might as well have the benefit.

So, we will do the extra registration and limit the back end changes to 
detect ConP occurrences in the AOTRuntimeConstants range and load them 
using an ExternalAddress reloc.

> I don't understand question about C1 (I am not familiar with it). What 
> it generates for shifts now? Why you need 3-operand shift?

I'm not sure '3-operand' is the right term to use to describe what is at 
stake here. It's really about the kind of operand rather than their 
number. The current region/card shift operations employ an immediate 
shift count. The AOT region/card shift operations need to be fed the 
shift count via a register (the target of the constant load).

C1 does currently generate shifts where the shift count is in a register 
but it only does so using the flavours of shift (sar/sal/shr/shl) that 
require the register to be ECX. It doesn't currently generate the 
alternative instructions (sarx/shlx/shrx) that accept a shift count in 
any register. I'm not 100% sure why but I think this is because not all 
CPUs implement them (they require CPUID feature BM2) or it may be to do 
with them setting/not setting flags.

Ashu is proposing adding support for these latter instructions to C1 so 
the barrier code does not have to pin the shift count to ECX. Do we 
care? Or can we live with the effect of pinning?

> Code style: I noticed and aarch64.ad still using old stile of 
> instructions definition using `enc_class`. We don't do this any more (at 
> least in x86*.ad) when we adding new instructions with one 
> implementation. Please use `ins_encode %{ %}` in such cases.

Sure, we will fix that.

> I think, if you need additional register you should push/pop to 
> guarantee we don't stomp over some used value.
Ok, we will play safe and do that.

One final comment: Much of this discussion is going to be side-stepped 
by the G1 late barrier implementation that is currently working its way 
into mainline. That will remove the need to inject barrier IR subgraphs 
into the C1 and C2 IR graphs and eliminate most (all?) of the associated 
C2 reduction rules from the ad files. I think we should still update the 
patch to accommodate the feedback above. We can simplify it further once 
the G1 changes come in from mainline and pursue in parallel the idea of 
accommodating changes to oop encodings using this model.

regards,


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


From vladimir.kozlov at oracle.com  Thu Aug 15 15:02:34 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 15 Aug 2024 08:02:34 -0700
Subject: [External] : Re: premain: Possible solutions to use runtime G1
 region grain size in AOT code (JDK-8335440)
In-Reply-To: <17da0ba4-1934-4f4f-804e-2a4ba6cef45e@redhat.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>
 <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>
 <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>
 <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>
 <84057040-3d3a-48be-88b3-502205ee6a7d@oracle.com>
 <a231c010-9fbc-485c-8e6e-6e8040524889@redhat.com>
 <b2f3983a-d6fa-4a07-a742-9e0c4a59e88d@oracle.com>
 <5e931bd6-c766-4939-b338-c60594b5e665@redhat.com>
 <5257f86c-2910-45c3-972f-929494fb3267@oracle.com>
 <3db5a5f3-41c3-4cfa-b446-273af5625ac1@redhat.com>
 <594256c5-b81d-453d-a4f4-6165b8368a9e@oracle.com>
 <CAKt0pyTjmXhXhk9snL3-D-qJo_S_H5c0A6HyxPkYcBSXR7jbLw@mail.gmail.com>
 <fdad55a9-50af-42c8-8a6a-f9f91a1a72f6@oracle.com>
 <17da0ba4-1934-4f4f-804e-2a4ba6cef45e@redhat.com>
Message-ID: <aa1679da-183a-480b-ac1e-9739c7198215@oracle.com>

 > Ashu is proposing adding support for these latter instructions to C1 so
 > the barrier code does not have to pin the shift count to ECX. Do we
 > care? Or can we live with the effect of pinning?

We only care about correctness currently. Performance (registers 
spilling) is not issue. And I am concern about size and complexity of 
Leyden specific changes which eventually will be pushed into mainline.
Unless you see benefits for new C1 shift instructions in mainline I 
would go with using ECX. And again, do this if code for using ECX is 
simpler than adding new instructions. If it is not - use new instructions.

I was hopping that "Late Barrier Expansion for G1" JEP may help here too 
but it has only C2 changes :(

I agree with updating this patch and may be even pushing it into premain 
(for testing) regardless "Late Barrier Expansion for G1" JEP status.

Thanks,
Vladimir K


On 8/15/24 3:18 AM, Andrew Dinn wrote:
> On 15/08/2024 00:50, Vladimir Kozlov wrote:
>> Do we really need AOTRuntimeConstants instance be a stub in CodeCache?
>> Looking on this code and I think this complicate implementation if use 
>> ExternalAddress relocation anyway. Can it be static instance in 
>> SCCache.cpp which we initialize the same way as in current changes?
> 
> Yes, you are right: we don't need the AOTRuntimeConstants struct to be 
> embedded in the cache if we are using an ExternalRelocation. The initial 
> idea for doing that was because it provides a 32-bit bound on the offset 
> from any struct field to a corresponding field load (lea). That would 
> allow us to use PC-relative loads of the field addresses -- which saves 
> instruction footprint on AArch64, possibly also on x86? However, we can 
> only do that if we also implement a new relocation (which seems 
> unnecessary).
> 
> So, we will redefine the AOTRuntimeConstants struct as a C++ static field.
> 
>> I do not understand why you have concern about having separate 
>> relocation for each constant in AOTRuntimeConstants. We have only 2 
>> now. Even they grow I don't think we will have a lot of them. Actually 
>> the question: will it simplify code if each constant's address is 
>> treated as separate and not offset in AOTRuntimeConstants? Instead of 
>> loading AOTRuntimeConstants address and then adding offset we just 
>> load address of constant.
> 
> Yes, you are right again: if we register the address of every field in 
> the struct in the SCC address table then that will simplify the back end 
> code. I was not sure how much we wanted to rely on address table 
> registration but given that we *are* reliant on it just now then we 
> might as well have the benefit.
> 
> So, we will do the extra registration and limit the back end changes to 
> detect ConP occurrences in the AOTRuntimeConstants range and load them 
> using an ExternalAddress reloc.
> 
>> I don't understand question about C1 (I am not familiar with it). What 
>> it generates for shifts now? Why you need 3-operand shift?
> 
> I'm not sure '3-operand' is the right term to use to describe what is at 
> stake here. It's really about the kind of operand rather than their 
> number. The current region/card shift operations employ an immediate 
> shift count. The AOT region/card shift operations need to be fed the 
> shift count via a register (the target of the constant load).
> 
> C1 does currently generate shifts where the shift count is in a register 
> but it only does so using the flavours of shift (sar/sal/shr/shl) that 
> require the register to be ECX. It doesn't currently generate the 
> alternative instructions (sarx/shlx/shrx) that accept a shift count in 
> any register. I'm not 100% sure why but I think this is because not all 
> CPUs implement them (they require CPUID feature BM2) or it may be to do 
> with them setting/not setting flags.
> 
> Ashu is proposing adding support for these latter instructions to C1 so 
> the barrier code does not have to pin the shift count to ECX. Do we 
> care? Or can we live with the effect of pinning?
> 
>> Code style: I noticed and aarch64.ad still using old stile of 
>> instructions definition using `enc_class`. We don't do this any more 
>> (at least in x86*.ad) when we adding new instructions with one 
>> implementation. Please use `ins_encode %{ %}` in such cases.
> 
> Sure, we will fix that.
> 
>> I think, if you need additional register you should push/pop to 
>> guarantee we don't stomp over some used value.
> Ok, we will play safe and do that.
> 
> One final comment: Much of this discussion is going to be side-stepped 
> by the G1 late barrier implementation that is currently working its way 
> into mainline. That will remove the need to inject barrier IR subgraphs 
> into the C1 and C2 IR graphs and eliminate most (all?) of the associated 
> C2 reduction rules from the ad files. I think we should still update the 
> patch to accommodate the feedback above. We can simplify it further once 
> the G1 changes come in from mainline and pursue in parallel the idea of 
> accommodating changes to oop encodings using this model.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> 

From asmehra at redhat.com  Thu Aug 15 20:43:22 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Thu, 15 Aug 2024 16:43:22 -0400
Subject: [External] : Re: premain: Possible solutions to use runtime G1
 region grain size in AOT code (JDK-8335440)
In-Reply-To: <aa1679da-183a-480b-ac1e-9739c7198215@oracle.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>
 <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>
 <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>
 <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>
 <84057040-3d3a-48be-88b3-502205ee6a7d@oracle.com>
 <a231c010-9fbc-485c-8e6e-6e8040524889@redhat.com>
 <b2f3983a-d6fa-4a07-a742-9e0c4a59e88d@oracle.com>
 <5e931bd6-c766-4939-b338-c60594b5e665@redhat.com>
 <5257f86c-2910-45c3-972f-929494fb3267@oracle.com>
 <3db5a5f3-41c3-4cfa-b446-273af5625ac1@redhat.com>
 <594256c5-b81d-453d-a4f4-6165b8368a9e@oracle.com>
 <CAKt0pyTjmXhXhk9snL3-D-qJo_S_H5c0A6HyxPkYcBSXR7jbLw@mail.gmail.com>
 <fdad55a9-50af-42c8-8a6a-f9f91a1a72f6@oracle.com>
 <17da0ba4-1934-4f4f-804e-2a4ba6cef45e@redhat.com>
 <aa1679da-183a-480b-ac1e-9739c7198215@oracle.com>
Message-ID: <CAKt0pyTGPpm5Qo2PmuoPiTdZaUTGas4XRYYdt=0Wf_eFSVWVgw@mail.gmail.com>

Hi Vladimir,
Here is the updated patch. We have refactored the code as per your
suggestions.
https://github.com/openjdk/leyden/compare/premain...ashu-mehra:leyden:JDK-8335440-load-via-codecache?expand=1

Let us know if you have any more suggestions.

Thanks,
- Ashutosh Mehra


On Thu, Aug 15, 2024 at 11:02?AM Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

>  > Ashu is proposing adding support for these latter instructions to C1 so
>  > the barrier code does not have to pin the shift count to ECX. Do we
>  > care? Or can we live with the effect of pinning?
>
> We only care about correctness currently. Performance (registers
> spilling) is not issue. And I am concern about size and complexity of
> Leyden specific changes which eventually will be pushed into mainline.
> Unless you see benefits for new C1 shift instructions in mainline I
> would go with using ECX. And again, do this if code for using ECX is
> simpler than adding new instructions. If it is not - use new instructions.
>
> I was hopping that "Late Barrier Expansion for G1" JEP may help here too
> but it has only C2 changes :(
>
> I agree with updating this patch and may be even pushing it into premain
> (for testing) regardless "Late Barrier Expansion for G1" JEP status.
>
> Thanks,
> Vladimir K
>
>
> On 8/15/24 3:18 AM, Andrew Dinn wrote:
> > On 15/08/2024 00:50, Vladimir Kozlov wrote:
> >> Do we really need AOTRuntimeConstants instance be a stub in CodeCache?
> >> Looking on this code and I think this complicate implementation if use
> >> ExternalAddress relocation anyway. Can it be static instance in
> >> SCCache.cpp which we initialize the same way as in current changes?
> >
> > Yes, you are right: we don't need the AOTRuntimeConstants struct to be
> > embedded in the cache if we are using an ExternalRelocation. The initial
> > idea for doing that was because it provides a 32-bit bound on the offset
> > from any struct field to a corresponding field load (lea). That would
> > allow us to use PC-relative loads of the field addresses -- which saves
> > instruction footprint on AArch64, possibly also on x86? However, we can
> > only do that if we also implement a new relocation (which seems
> > unnecessary).
> >
> > So, we will redefine the AOTRuntimeConstants struct as a C++ static
> field.
> >
> >> I do not understand why you have concern about having separate
> >> relocation for each constant in AOTRuntimeConstants. We have only 2
> >> now. Even they grow I don't think we will have a lot of them. Actually
> >> the question: will it simplify code if each constant's address is
> >> treated as separate and not offset in AOTRuntimeConstants? Instead of
> >> loading AOTRuntimeConstants address and then adding offset we just
> >> load address of constant.
> >
> > Yes, you are right again: if we register the address of every field in
> > the struct in the SCC address table then that will simplify the back end
> > code. I was not sure how much we wanted to rely on address table
> > registration but given that we *are* reliant on it just now then we
> > might as well have the benefit.
> >
> > So, we will do the extra registration and limit the back end changes to
> > detect ConP occurrences in the AOTRuntimeConstants range and load them
> > using an ExternalAddress reloc.
> >
> >> I don't understand question about C1 (I am not familiar with it). What
> >> it generates for shifts now? Why you need 3-operand shift?
> >
> > I'm not sure '3-operand' is the right term to use to describe what is at
> > stake here. It's really about the kind of operand rather than their
> > number. The current region/card shift operations employ an immediate
> > shift count. The AOT region/card shift operations need to be fed the
> > shift count via a register (the target of the constant load).
> >
> > C1 does currently generate shifts where the shift count is in a register
> > but it only does so using the flavours of shift (sar/sal/shr/shl) that
> > require the register to be ECX. It doesn't currently generate the
> > alternative instructions (sarx/shlx/shrx) that accept a shift count in
> > any register. I'm not 100% sure why but I think this is because not all
> > CPUs implement them (they require CPUID feature BM2) or it may be to do
> > with them setting/not setting flags.
> >
> > Ashu is proposing adding support for these latter instructions to C1 so
> > the barrier code does not have to pin the shift count to ECX. Do we
> > care? Or can we live with the effect of pinning?
> >
> >> Code style: I noticed and aarch64.ad still using old stile of
> >> instructions definition using `enc_class`. We don't do this any more
> >> (at least in x86*.ad) when we adding new instructions with one
> >> implementation. Please use `ins_encode %{ %}` in such cases.
> >
> > Sure, we will fix that.
> >
> >> I think, if you need additional register you should push/pop to
> >> guarantee we don't stomp over some used value.
> > Ok, we will play safe and do that.
> >
> > One final comment: Much of this discussion is going to be side-stepped
> > by the G1 late barrier implementation that is currently working its way
> > into mainline. That will remove the need to inject barrier IR subgraphs
> > into the C1 and C2 IR graphs and eliminate most (all?) of the associated
> > C2 reduction rules from the ad files. I think we should still update the
> > patch to accommodate the feedback above. We can simplify it further once
> > the G1 changes come in from mainline and pursue in parallel the idea of
> > accommodating changes to oop encodings using this model.
> >
> > regards,
> >
> >
> > Andrew Dinn
> > -----------
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240815/9f100168/attachment.htm>

From shipilev at amazon.de  Thu Aug 15 21:47:02 2024
From: shipilev at amazon.de (Aleksey Shipilev)
Date: Thu, 15 Aug 2024 23:47:02 +0200
Subject: Enabling clean PRs in Leyden
Message-ID: <70a7b55d-f286-4a85-9585-77b791160403@amazon.de>

Hi,

Here is a short list of things in progress to make PR workflows useful in Leyden:

1. Enable Skara bots to show GHA results:
  https://bugs.openjdk.org/browse/SKARA-2353

2. jcheck configuration for the repository:
  https://github.com/openjdk/leyden/pull/11

3. Code changes to make most (all?) builds clean:
  (this one is progress, I need to confirm all GHA jobs are green)
  https://github.com/openjdk/leyden/pull/10


-- 
Thanks,
-Aleksey



Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

From ioi.lam at oracle.com  Thu Aug 15 21:57:07 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Thu, 15 Aug 2024 14:57:07 -0700
Subject: Proposal: Replace -XX:CacheDataStore with new "AOT" naming scheme
Message-ID: <2bb9f7e0-1081-4634-92e6-36aa7cb74538@oracle.com>

Hi folks,

I've filed https://bugs.openjdk.org/browse/JDK-8338476 to rename 
-XX:CacheDataStore.

Any comments? Without any strong objections I will implement this shortly.

Thanks

- Ioi

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

As part of JEP 483, we are adding new -XX:AOTXxx flags (see JDK-8338017) 
for controlling ahead-of-time optimizations. The -XX:CacheDataStore flag 
in the leyden/premain should be renamed to be consistent with the new 
naming scheme.

Also, -XX:CacheDataStore=foo has automagic behavior -- if foo exists, 
load it as the CDS archive; otherwise create foo at VM exit. While such 
automagic behavior might be convenient for desktop users, it's not 
particular useful for early adopters of Leyden -- i.e., developers who 
are packaging apps for cloud deployment. For example, to make sure that 
foo is created, you would need to remove it explicitly:

 ??? rm -f foo
 ??? java -XX:CacheDataStore=foo -cp app.jar ...

Proposal:

In JEP 483, AOTConfiguration is required for creating an AOTCache. E.g.,

 ??? java -XX:AOTMode=create -XX:AOTCache=foo.aot \
 ??????? -XX:AOTConfiguration=foo.aotconfig \
 ??????? -cp app.jar ...

In the leyden/premain branch, we allow the AOTConfiguration flag to be 
omitted. In this case, the application will be executed once and the 
AOTCache will be created at VM exit:

 ??? java -XX:AOTMode=create -XX:AOTCache=foo.aot \
 ??????? -cp app.jar ...

Also, in this mode, all Leyden optimizations (such as 
-XX:+StoreCachedCode) are enabled by default (this is the same behavior 
as with -XX:CacheDataStore).


From vladimir.kozlov at oracle.com  Thu Aug 15 22:06:23 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 15 Aug 2024 15:06:23 -0700
Subject: [External] : Re: premain: Possible solutions to use runtime G1
 region grain size in AOT code (JDK-8335440)
In-Reply-To: <CAKt0pyTGPpm5Qo2PmuoPiTdZaUTGas4XRYYdt=0Wf_eFSVWVgw@mail.gmail.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>
 <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>
 <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>
 <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>
 <84057040-3d3a-48be-88b3-502205ee6a7d@oracle.com>
 <a231c010-9fbc-485c-8e6e-6e8040524889@redhat.com>
 <b2f3983a-d6fa-4a07-a742-9e0c4a59e88d@oracle.com>
 <5e931bd6-c766-4939-b338-c60594b5e665@redhat.com>
 <5257f86c-2910-45c3-972f-929494fb3267@oracle.com>
 <3db5a5f3-41c3-4cfa-b446-273af5625ac1@redhat.com>
 <594256c5-b81d-453d-a4f4-6165b8368a9e@oracle.com>
 <CAKt0pyTjmXhXhk9snL3-D-qJo_S_H5c0A6HyxPkYcBSXR7jbLw@mail.gmail.com>
 <fdad55a9-50af-42c8-8a6a-f9f91a1a72f6@oracle.com>
 <17da0ba4-1934-4f4f-804e-2a4ba6cef45e@redhat.com>
 <aa1679da-183a-480b-ac1e-9739c7198215@oracle.com>
 <CAKt0pyTGPpm5Qo2PmuoPiTdZaUTGas4XRYYdt=0Wf_eFSVWVgw@mail.gmail.com>
Message-ID: <e855be08-53f8-4825-959d-81f9016f5802@oracle.com>

No.

Why you still use base+offsets for constants address? Is it for Aarch64?

What I want is something like this:

static address grain_shift_address() { return 
&_aot_runtime_constants::_grain_shift; }

And you will not need `#if INCLUDE_CDS` if you put AOTRuntimeConstants 
into SCCache.cpp.

I don't see the need to separate create_field_address_list() code from 
field_addresses_list().

Add assert to field_addresses_list() to check that values are initialized.

Vladimir K

On 8/15/24 1:43 PM, Ashutosh Mehra wrote:
> Hi Vladimir,
> Here is the updated patch. We have refactored the code as per your 
> suggestions.
> https://github.com/openjdk/leyden/compare/premain...ashu-mehra:leyden:JDK-8335440-load-via-codecache?expand=1 <https://urldefense.com/v3/__https://github.com/openjdk/leyden/compare/premain...ashu-mehra:leyden:JDK-8335440-load-via-codecache?expand=1__;!!ACWV5N9M2RV99hQ!KJr_KHIS5usVHG5WgzaX4UOvAVI4Y2Z-ZoblB2fhuGsj2i-89W0RoSddeMDGtpieLZydGC4pagdnoaYt2zbt_w$>
> 
> Let us know if?you have any more suggestions.
> 
> Thanks,
> - Ashutosh Mehra
> 
> 
> On Thu, Aug 15, 2024 at 11:02?AM Vladimir Kozlov 
> <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
> 
>      ?> Ashu is proposing adding support for these latter instructions
>     to C1 so
>      ?> the barrier code does not have to pin the shift count to ECX. Do we
>      ?> care? Or can we live with the effect of pinning?
> 
>     We only care about correctness currently. Performance (registers
>     spilling) is not issue. And I am concern about size and complexity of
>     Leyden specific changes which eventually will be pushed into mainline.
>     Unless you see benefits for new C1 shift instructions in mainline I
>     would go with using ECX. And again, do this if code for using ECX is
>     simpler than adding new instructions. If it is not - use new
>     instructions.
> 
>     I was hopping that "Late Barrier Expansion for G1" JEP may help here
>     too
>     but it has only C2 changes :(
> 
>     I agree with updating this patch and may be even pushing it into
>     premain
>     (for testing) regardless "Late Barrier Expansion for G1" JEP status.
> 
>     Thanks,
>     Vladimir K
> 
> 
>     On 8/15/24 3:18 AM, Andrew Dinn wrote:
>      > On 15/08/2024 00:50, Vladimir Kozlov wrote:
>      >> Do we really need AOTRuntimeConstants instance be a stub in
>     CodeCache?
>      >> Looking on this code and I think this complicate implementation
>     if use
>      >> ExternalAddress relocation anyway. Can it be static instance in
>      >> SCCache.cpp which we initialize the same way as in current changes?
>      >
>      > Yes, you are right: we don't need the AOTRuntimeConstants struct
>     to be
>      > embedded in the cache if we are using an ExternalRelocation. The
>     initial
>      > idea for doing that was because it provides a 32-bit bound on the
>     offset
>      > from any struct field to a corresponding field load (lea). That
>     would
>      > allow us to use PC-relative loads of the field addresses -- which
>     saves
>      > instruction footprint on AArch64, possibly also on x86? However,
>     we can
>      > only do that if we also implement a new relocation (which seems
>      > unnecessary).
>      >
>      > So, we will redefine the AOTRuntimeConstants struct as a C++
>     static field.
>      >
>      >> I do not understand why you have concern about having separate
>      >> relocation for each constant in AOTRuntimeConstants. We have only 2
>      >> now. Even they grow I don't think we will have a lot of them.
>     Actually
>      >> the question: will it simplify code if each constant's address is
>      >> treated as separate and not offset in AOTRuntimeConstants?
>     Instead of
>      >> loading AOTRuntimeConstants address and then adding offset we just
>      >> load address of constant.
>      >
>      > Yes, you are right again: if we register the address of every
>     field in
>      > the struct in the SCC address table then that will simplify the
>     back end
>      > code. I was not sure how much we wanted to rely on address table
>      > registration but given that we *are* reliant on it just now then we
>      > might as well have the benefit.
>      >
>      > So, we will do the extra registration and limit the back end
>     changes to
>      > detect ConP occurrences in the AOTRuntimeConstants range and load
>     them
>      > using an ExternalAddress reloc.
>      >
>      >> I don't understand question about C1 (I am not familiar with
>     it). What
>      >> it generates for shifts now? Why you need 3-operand shift?
>      >
>      > I'm not sure '3-operand' is the right term to use to describe
>     what is at
>      > stake here. It's really about the kind of operand rather than their
>      > number. The current region/card shift operations employ an immediate
>      > shift count. The AOT region/card shift operations need to be fed the
>      > shift count via a register (the target of the constant load).
>      >
>      > C1 does currently generate shifts where the shift count is in a
>     register
>      > but it only does so using the flavours of shift (sar/sal/shr/shl)
>     that
>      > require the register to be ECX. It doesn't currently generate the
>      > alternative instructions (sarx/shlx/shrx) that accept a shift
>     count in
>      > any register. I'm not 100% sure why but I think this is because
>     not all
>      > CPUs implement them (they require CPUID feature BM2) or it may be
>     to do
>      > with them setting/not setting flags.
>      >
>      > Ashu is proposing adding support for these latter instructions to
>     C1 so
>      > the barrier code does not have to pin the shift count to ECX. Do we
>      > care? Or can we live with the effect of pinning?
>      >
>      >> Code style: I noticed and aarch64.ad
>     <https://urldefense.com/v3/__http://aarch64.ad__;!!ACWV5N9M2RV99hQ!KJr_KHIS5usVHG5WgzaX4UOvAVI4Y2Z-ZoblB2fhuGsj2i-89W0RoSddeMDGtpieLZydGC4pagdnoaYhejMFCA$> still using old stile of
>      >> instructions definition using `enc_class`. We don't do this any
>     more
>      >> (at least in x86*.ad) when we adding new instructions with one
>      >> implementation. Please use `ins_encode %{ %}` in such cases.
>      >
>      > Sure, we will fix that.
>      >
>      >> I think, if you need additional register you should push/pop to
>      >> guarantee we don't stomp over some used value.
>      > Ok, we will play safe and do that.
>      >
>      > One final comment: Much of this discussion is going to be
>     side-stepped
>      > by the G1 late barrier implementation that is currently working
>     its way
>      > into mainline. That will remove the need to inject barrier IR
>     subgraphs
>      > into the C1 and C2 IR graphs and eliminate most (all?) of the
>     associated
>      > C2 reduction rules from the ad files. I think we should still
>     update the
>      > patch to accommodate the feedback above. We can simplify it
>     further once
>      > the G1 changes come in from mainline and pursue in parallel the
>     idea of
>      > accommodating changes to oop encodings using this model.
>      >
>      > regards,
>      >
>      >
>      > Andrew Dinn
>      > -----------
>      >
> 

From vladimir.kozlov at oracle.com  Thu Aug 15 22:21:09 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 15 Aug 2024 15:21:09 -0700
Subject: Proposal: Replace -XX:CacheDataStore with new "AOT" naming scheme
In-Reply-To: <2bb9f7e0-1081-4634-92e6-36aa7cb74538@oracle.com>
References: <2bb9f7e0-1081-4634-92e6-36aa7cb74538@oracle.com>
Message-ID: <81a97bce-3a73-4c2c-b318-66ac10eb5d20@oracle.com>

java -XX:AOTMode=create -XX:AOTCache=foo.aot -cp app.jar ...

This is for one step workflow.

For 5 steps workflow (which we still support for development) we may 
need all flags from JEP. Or it is different RFE?

Vladimir K

On 8/15/24 2:57 PM, ioi.lam at oracle.com wrote:
> Hi folks,
> 
> I've filed https://bugs.openjdk.org/browse/JDK-8338476 to rename 
> -XX:CacheDataStore.
> 
> Any comments? Without any strong objections I will implement this shortly.
> 
> Thanks
> 
> - Ioi
> 
> ------------------------------------------
> 
> As part of JEP 483, we are adding new -XX:AOTXxx flags (see JDK-8338017) 
> for controlling ahead-of-time optimizations. The -XX:CacheDataStore flag 
> in the leyden/premain should be renamed to be consistent with the new 
> naming scheme.
> 
> Also, -XX:CacheDataStore=foo has automagic behavior -- if foo exists, 
> load it as the CDS archive; otherwise create foo at VM exit. While such 
> automagic behavior might be convenient for desktop users, it's not 
> particular useful for early adopters of Leyden -- i.e., developers who 
> are packaging apps for cloud deployment. For example, to make sure that 
> foo is created, you would need to remove it explicitly:
> 
>  ??? rm -f foo
>  ??? java -XX:CacheDataStore=foo -cp app.jar ...
> 
> Proposal:
> 
> In JEP 483, AOTConfiguration is required for creating an AOTCache. E.g.,
> 
>  ??? java -XX:AOTMode=create -XX:AOTCache=foo.aot \
>  ??????? -XX:AOTConfiguration=foo.aotconfig \
>  ??????? -cp app.jar ...
> 
> In the leyden/premain branch, we allow the AOTConfiguration flag to be 
> omitted. In this case, the application will be executed once and the 
> AOTCache will be created at VM exit:
> 
>  ??? java -XX:AOTMode=create -XX:AOTCache=foo.aot \
>  ??????? -cp app.jar ...
> 
> Also, in this mode, all Leyden optimizations (such as 
> -XX:+StoreCachedCode) are enabled by default (this is the same behavior 
> as with -XX:CacheDataStore).
> 

From vladimir.kozlov at oracle.com  Thu Aug 15 22:21:44 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 15 Aug 2024 15:21:44 -0700
Subject: Enabling clean PRs in Leyden
In-Reply-To: <70a7b55d-f286-4a85-9585-77b791160403@amazon.de>
References: <70a7b55d-f286-4a85-9585-77b791160403@amazon.de>
Message-ID: <09fa411d-de58-4d1e-acc8-34add8412d72@oracle.com>

Thank you, Aleksey

Vladimir K

On 8/15/24 2:47 PM, Aleksey Shipilev wrote:
> Hi,
> 
> Here is a short list of things in progress to make PR workflows useful 
> in Leyden:
> 
> 1. Enable Skara bots to show GHA results:
>  ?https://bugs.openjdk.org/browse/SKARA-2353
> 
> 2. jcheck configuration for the repository:
>  ?https://github.com/openjdk/leyden/pull/11
> 
> 3. Code changes to make most (all?) builds clean:
>  ?(this one is progress, I need to confirm all GHA jobs are green)
>  ?https://github.com/openjdk/leyden/pull/10
> 
> 

From vladimir.kozlov at oracle.com  Thu Aug 15 22:30:37 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 15 Aug 2024 15:30:37 -0700
Subject: [External] : Re: premain: Possible solutions to use runtime G1
 region grain size in AOT code (JDK-8335440)
In-Reply-To: <e855be08-53f8-4825-959d-81f9016f5802@oracle.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>
 <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>
 <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>
 <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>
 <84057040-3d3a-48be-88b3-502205ee6a7d@oracle.com>
 <a231c010-9fbc-485c-8e6e-6e8040524889@redhat.com>
 <b2f3983a-d6fa-4a07-a742-9e0c4a59e88d@oracle.com>
 <5e931bd6-c766-4939-b338-c60594b5e665@redhat.com>
 <5257f86c-2910-45c3-972f-929494fb3267@oracle.com>
 <3db5a5f3-41c3-4cfa-b446-273af5625ac1@redhat.com>
 <594256c5-b81d-453d-a4f4-6165b8368a9e@oracle.com>
 <CAKt0pyTjmXhXhk9snL3-D-qJo_S_H5c0A6HyxPkYcBSXR7jbLw@mail.gmail.com>
 <fdad55a9-50af-42c8-8a6a-f9f91a1a72f6@oracle.com>
 <17da0ba4-1934-4f4f-804e-2a4ba6cef45e@redhat.com>
 <aa1679da-183a-480b-ac1e-9739c7198215@oracle.com>
 <CAKt0pyTGPpm5Qo2PmuoPiTdZaUTGas4XRYYdt=0Wf_eFSVWVgw@mail.gmail.com>
 <e855be08-53f8-4825-959d-81f9016f5802@oracle.com>
Message-ID: <0916b5e3-3d5f-40bd-94b2-9eb01f600c60@oracle.com>

On 8/15/24 3:06 PM, Vladimir Kozlov wrote:
> No.
> 
> Why you still use base+offsets for constants address? Is it for Aarch64?
> 
> What I want is something like this:
> 
> static address grain_shift_address() { return 
> &_aot_runtime_constants::_grain_shift; }
> 
> And you will not need `#if INCLUDE_CDS` if you put AOTRuntimeConstants 
> into SCCache.cpp.
> 
> I don't see the need to separate create_field_address_list() code from 
> field_addresses_list().
> 
> Add assert to field_addresses_list() to check that values are initialized.

Actually you don't need assert since we need only addresses of fields.

I don't see use of aot_runtime_constants_at() anymore.

Also why you need aot_runtime_constants()? Why not have 
_aot_runtime_constants as static field of AOTRuntimeConstants class 
which you can initialize in (again) SCCache.cpp?

Vladimir K

> 
> Vladimir K
> 
> On 8/15/24 1:43 PM, Ashutosh Mehra wrote:
>> Hi Vladimir,
>> Here is the updated patch. We have refactored the code as per your 
>> suggestions.
>> https://github.com/openjdk/leyden/compare/premain...ashu-mehra:leyden:JDK-8335440-load-via-codecache?expand=1 <https://urldefense.com/v3/__https://github.com/openjdk/leyden/compare/premain...ashu-mehra:leyden:JDK-8335440-load-via-codecache?expand=1__;!!ACWV5N9M2RV99hQ!KJr_KHIS5usVHG5WgzaX4UOvAVI4Y2Z-ZoblB2fhuGsj2i-89W0RoSddeMDGtpieLZydGC4pagdnoaYt2zbt_w$>
>>
>> Let us know if?you have any more suggestions.
>>
>> Thanks,
>> - Ashutosh Mehra
>>
>>
>> On Thu, Aug 15, 2024 at 11:02?AM Vladimir Kozlov 
>> <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>
>> ???? ?> Ashu is proposing adding support for these latter instructions
>> ??? to C1 so
>> ???? ?> the barrier code does not have to pin the shift count to ECX. 
>> Do we
>> ???? ?> care? Or can we live with the effect of pinning?
>>
>> ??? We only care about correctness currently. Performance (registers
>> ??? spilling) is not issue. And I am concern about size and complexity of
>> ??? Leyden specific changes which eventually will be pushed into 
>> mainline.
>> ??? Unless you see benefits for new C1 shift instructions in mainline I
>> ??? would go with using ECX. And again, do this if code for using ECX is
>> ??? simpler than adding new instructions. If it is not - use new
>> ??? instructions.
>>
>> ??? I was hopping that "Late Barrier Expansion for G1" JEP may help here
>> ??? too
>> ??? but it has only C2 changes :(
>>
>> ??? I agree with updating this patch and may be even pushing it into
>> ??? premain
>> ??? (for testing) regardless "Late Barrier Expansion for G1" JEP status.
>>
>> ??? Thanks,
>> ??? Vladimir K
>>
>>
>> ??? On 8/15/24 3:18 AM, Andrew Dinn wrote:
>> ???? > On 15/08/2024 00:50, Vladimir Kozlov wrote:
>> ???? >> Do we really need AOTRuntimeConstants instance be a stub in
>> ??? CodeCache?
>> ???? >> Looking on this code and I think this complicate implementation
>> ??? if use
>> ???? >> ExternalAddress relocation anyway. Can it be static instance in
>> ???? >> SCCache.cpp which we initialize the same way as in current 
>> changes?
>> ???? >
>> ???? > Yes, you are right: we don't need the AOTRuntimeConstants struct
>> ??? to be
>> ???? > embedded in the cache if we are using an ExternalRelocation. The
>> ??? initial
>> ???? > idea for doing that was because it provides a 32-bit bound on the
>> ??? offset
>> ???? > from any struct field to a corresponding field load (lea). That
>> ??? would
>> ???? > allow us to use PC-relative loads of the field addresses -- which
>> ??? saves
>> ???? > instruction footprint on AArch64, possibly also on x86? However,
>> ??? we can
>> ???? > only do that if we also implement a new relocation (which seems
>> ???? > unnecessary).
>> ???? >
>> ???? > So, we will redefine the AOTRuntimeConstants struct as a C++
>> ??? static field.
>> ???? >
>> ???? >> I do not understand why you have concern about having separate
>> ???? >> relocation for each constant in AOTRuntimeConstants. We have 
>> only 2
>> ???? >> now. Even they grow I don't think we will have a lot of them.
>> ??? Actually
>> ???? >> the question: will it simplify code if each constant's address is
>> ???? >> treated as separate and not offset in AOTRuntimeConstants?
>> ??? Instead of
>> ???? >> loading AOTRuntimeConstants address and then adding offset we 
>> just
>> ???? >> load address of constant.
>> ???? >
>> ???? > Yes, you are right again: if we register the address of every
>> ??? field in
>> ???? > the struct in the SCC address table then that will simplify the
>> ??? back end
>> ???? > code. I was not sure how much we wanted to rely on address table
>> ???? > registration but given that we *are* reliant on it just now 
>> then we
>> ???? > might as well have the benefit.
>> ???? >
>> ???? > So, we will do the extra registration and limit the back end
>> ??? changes to
>> ???? > detect ConP occurrences in the AOTRuntimeConstants range and load
>> ??? them
>> ???? > using an ExternalAddress reloc.
>> ???? >
>> ???? >> I don't understand question about C1 (I am not familiar with
>> ??? it). What
>> ???? >> it generates for shifts now? Why you need 3-operand shift?
>> ???? >
>> ???? > I'm not sure '3-operand' is the right term to use to describe
>> ??? what is at
>> ???? > stake here. It's really about the kind of operand rather than 
>> their
>> ???? > number. The current region/card shift operations employ an 
>> immediate
>> ???? > shift count. The AOT region/card shift operations need to be 
>> fed the
>> ???? > shift count via a register (the target of the constant load).
>> ???? >
>> ???? > C1 does currently generate shifts where the shift count is in a
>> ??? register
>> ???? > but it only does so using the flavours of shift (sar/sal/shr/shl)
>> ??? that
>> ???? > require the register to be ECX. It doesn't currently generate the
>> ???? > alternative instructions (sarx/shlx/shrx) that accept a shift
>> ??? count in
>> ???? > any register. I'm not 100% sure why but I think this is because
>> ??? not all
>> ???? > CPUs implement them (they require CPUID feature BM2) or it may be
>> ??? to do
>> ???? > with them setting/not setting flags.
>> ???? >
>> ???? > Ashu is proposing adding support for these latter instructions to
>> ??? C1 so
>> ???? > the barrier code does not have to pin the shift count to ECX. 
>> Do we
>> ???? > care? Or can we live with the effect of pinning?
>> ???? >
>> ???? >> Code style: I noticed and aarch64.ad
>>     
>> <https://urldefense.com/v3/__http://aarch64.ad__;!!ACWV5N9M2RV99hQ!KJr_KHIS5usVHG5WgzaX4UOvAVI4Y2Z-ZoblB2fhuGsj2i-89W0RoSddeMDGtpieLZydGC4pagdnoaYhejMFCA$> still using old stile of
>> ???? >> instructions definition using `enc_class`. We don't do this any
>> ??? more
>> ???? >> (at least in x86*.ad) when we adding new instructions with one
>> ???? >> implementation. Please use `ins_encode %{ %}` in such cases.
>> ???? >
>> ???? > Sure, we will fix that.
>> ???? >
>> ???? >> I think, if you need additional register you should push/pop to
>> ???? >> guarantee we don't stomp over some used value.
>> ???? > Ok, we will play safe and do that.
>> ???? >
>> ???? > One final comment: Much of this discussion is going to be
>> ??? side-stepped
>> ???? > by the G1 late barrier implementation that is currently working
>> ??? its way
>> ???? > into mainline. That will remove the need to inject barrier IR
>> ??? subgraphs
>> ???? > into the C1 and C2 IR graphs and eliminate most (all?) of the
>> ??? associated
>> ???? > C2 reduction rules from the ad files. I think we should still
>> ??? update the
>> ???? > patch to accommodate the feedback above. We can simplify it
>> ??? further once
>> ???? > the G1 changes come in from mainline and pursue in parallel the
>> ??? idea of
>> ???? > accommodating changes to oop encodings using this model.
>> ???? >
>> ???? > regards,
>> ???? >
>> ???? >
>> ???? > Andrew Dinn
>> ???? > -----------
>> ???? >
>>

From stephane.nicoll at broadcom.com  Fri Aug 16 06:08:36 2024
From: stephane.nicoll at broadcom.com (Stephane Nicoll)
Date: Fri, 16 Aug 2024 08:08:36 +0200
Subject: Proposal: Replace -XX:CacheDataStore with new "AOT" naming scheme
In-Reply-To: <2bb9f7e0-1081-4634-92e6-36aa7cb74538@oracle.com>
References: <2bb9f7e0-1081-4634-92e6-36aa7cb74538@oracle.com>
Message-ID: <CANqHJzB0cvHHafwkzT6-jnOSxRy3AfS8cCU+OU6U18WQqOqbuQ@mail.gmail.com>

This looks good and having shorter configuration switches is better, IMO.

Thanks!

On Thu, Aug 15, 2024 at 11:57?PM <ioi.lam at oracle.com> wrote:

> Hi folks,
>
> I've filed https://bugs.openjdk.org/browse/JDK-8338476 to rename
> -XX:CacheDataStore.
>
> Any comments? Without any strong objections I will implement this shortly.
>
> Thanks
>
> - Ioi
>
> ------------------------------------------
>
> As part of JEP 483, we are adding new -XX:AOTXxx flags (see JDK-8338017)
> for controlling ahead-of-time optimizations. The -XX:CacheDataStore flag
> in the leyden/premain should be renamed to be consistent with the new
> naming scheme.
>
> Also, -XX:CacheDataStore=foo has automagic behavior -- if foo exists,
> load it as the CDS archive; otherwise create foo at VM exit. While such
> automagic behavior might be convenient for desktop users, it's not
> particular useful for early adopters of Leyden -- i.e., developers who
> are packaging apps for cloud deployment. For example, to make sure that
> foo is created, you would need to remove it explicitly:
>
>      rm -f foo
>      java -XX:CacheDataStore=foo -cp app.jar ...
>
> Proposal:
>
> In JEP 483, AOTConfiguration is required for creating an AOTCache. E.g.,
>
>      java -XX:AOTMode=create -XX:AOTCache=foo.aot \
>          -XX:AOTConfiguration=foo.aotconfig \
>          -cp app.jar ...
>
> In the leyden/premain branch, we allow the AOTConfiguration flag to be
> omitted. In this case, the application will be executed once and the
> AOTCache will be created at VM exit:
>
>      java -XX:AOTMode=create -XX:AOTCache=foo.aot \
>          -cp app.jar ...
>
> Also, in this mode, all Leyden optimizations (such as
> -XX:+StoreCachedCode) are enabled by default (this is the same behavior
> as with -XX:CacheDataStore).
>
>

-- 
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/20240816/eb1d9f2b/attachment.htm>

From ioi.lam at oracle.com  Fri Aug 16 17:00:01 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Fri, 16 Aug 2024 10:00:01 -0700
Subject: Proposal: Replace -XX:CacheDataStore with new "AOT" naming scheme
In-Reply-To: <81a97bce-3a73-4c2c-b318-66ac10eb5d20@oracle.com>
References: <2bb9f7e0-1081-4634-92e6-36aa7cb74538@oracle.com>
 <81a97bce-3a73-4c2c-b318-66ac10eb5d20@oracle.com>
Message-ID: <01a44ebc-8aff-4ef4-9910-f19dcef0f8a3@oracle.com>


On 8/15/24 3:21 PM, Vladimir Kozlov wrote:
> java -XX:AOTMode=create -XX:AOTCache=foo.aot -cp app.jar ...
>
> This is for one step workflow.
>
Mark suggested that we shouldn't rely on the lack of an argument 
(AOTConfiguration) to trigger a new behavior. Instead, he suggested

 ??? java -XX:AOTMode=train -XX:AOTCache=foo.aot -cp app.jar ...

which I think is a good idea.

> For 5 steps workflow (which we still support for development) we may 
> need all flags from JEP. Or it is different RFE?
>
I think we should just deprecate (and remove) the 5 step workflow.

Thanks

- Ioi


> Vladimir K
>
> On 8/15/24 2:57 PM, ioi.lam at oracle.com wrote:
>> Hi folks,
>>
>> I've filed https://bugs.openjdk.org/browse/JDK-8338476 to rename 
>> -XX:CacheDataStore.
>>
>> Any comments? Without any strong objections I will implement this 
>> shortly.
>>
>> Thanks
>>
>> - Ioi
>>
>> ------------------------------------------
>>
>> As part of JEP 483, we are adding new -XX:AOTXxx flags (see 
>> JDK-8338017) for controlling ahead-of-time optimizations. The 
>> -XX:CacheDataStore flag in the leyden/premain should be renamed to be 
>> consistent with the new naming scheme.
>>
>> Also, -XX:CacheDataStore=foo has automagic behavior -- if foo exists, 
>> load it as the CDS archive; otherwise create foo at VM exit. While 
>> such automagic behavior might be convenient for desktop users, it's 
>> not particular useful for early adopters of Leyden -- i.e., 
>> developers who are packaging apps for cloud deployment. For example, 
>> to make sure that foo is created, you would need to remove it 
>> explicitly:
>>
>> ???? rm -f foo
>> ???? java -XX:CacheDataStore=foo -cp app.jar ...
>>
>> Proposal:
>>
>> In JEP 483, AOTConfiguration is required for creating an AOTCache. E.g.,
>>
>> ???? java -XX:AOTMode=create -XX:AOTCache=foo.aot \
>> ???????? -XX:AOTConfiguration=foo.aotconfig \
>> ???????? -cp app.jar ...
>>
>> In the leyden/premain branch, we allow the AOTConfiguration flag to 
>> be omitted. In this case, the application will be executed once and 
>> the AOTCache will be created at VM exit:
>>
>> ???? java -XX:AOTMode=create -XX:AOTCache=foo.aot \
>> ???????? -cp app.jar ...
>>
>> Also, in this mode, all Leyden optimizations (such as 
>> -XX:+StoreCachedCode) are enabled by default (this is the same 
>> behavior as with -XX:CacheDataStore).
>>

From duke at openjdk.org  Fri Aug 16 17:04:52 2024
From: duke at openjdk.org (duke)
Date: Fri, 16 Aug 2024 17:04:52 GMT
Subject: git: openjdk/leyden: premain: jcheck configuration for Leyden
Message-ID: <55f5b42b-1c93-4053-b73e-1dcc533b9106@openjdk.org>

Changeset: 2158a6a5
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: iklam <ilam3388 at gmail.com>
Date:      2024-08-15 15:45:08 +0000
URL:       https://git.openjdk.org/leyden/commit/2158a6a5e0e4b19a2d514dd9864427dabc9f39d5

jcheck configuration for Leyden

! .jcheck/conf


From john.r.rose at oracle.com  Fri Aug 16 23:50:41 2024
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 16 Aug 2024 19:50:41 -0400
Subject: EA feedback
In-Reply-To: <bcf26ac8-663f-4b11-abb3-1ca942d506e2@oracle.com>
References: <CAABjz10oAmoLkEfLSLo0MN7+BzCFQJ5VYSkmhWH6GB6SVrF57Q@mail.gmail.com>
 <CAKt0pySHtZHSk0FyarM7kkdygTBppHBcYfpXPOfiJuS+7qjQyg@mail.gmail.com>
 <bcf26ac8-663f-4b11-abb3-1ca942d506e2@oracle.com>
Message-ID: <A0C193BF-B8DB-4BC6-95D5-BBA21DC92F27@oracle.com>

Here?s the way I would prefer to think about a ?dump command?.

The native way that the JVM represents sequential operations is
the method.  Talking about methods is therefore a basic way to
specify a condition for injecting a JVM operation like training
dumps.  I would like to figure out a good way to tie the training
dump to the invocation of a method, either a single well-known
method, or to a method specified (on the command line) by the
user.

In fact, it feels like a breakpoint-like operation would be a
natural way to view the training dump.  You don?t need JVMTI
to get it done; you just need a hack in the VM which parallels
the existing breakpoint mechanism, but special-cases it to
drive a training dump.

Given such a foundation, jsig could then inject a call to a
method which is appropriately tied to the dump command.

Sketch of implementation:

When a method is first linked, a list is checked to see if
it has a dump event tied to it, and a bit is set on the method.
The method?s interpreter entry point might be modified, or
perhaps the interpreter just always checks the bit.  On entry
to the method, before the first bytecode, an upcall tells
the VM that it?s time to finish the training run.

The compilers also check this bit, of course.

There is some method deep in the privates of java.base
that is always treated this way.  That?s what jcmd reaches.
There is a command line option which lists more methods
to treat this way, something like the CompileOnly command.

As a separate option, the upcall to end the training run
might return (allowing the VM to continue) or just exit.

As a separate option, allow the user to specify a count N,
so that the training dump happens only after N ?hits? on
any marked method(s).

I think all this is useful and flexible.

On 13 Aug 2024, at 18:22, ioi.lam at oracle.com wrote:

> On 8/13/24 12:42 PM, Ashutosh Mehra wrote:
>>
>>     Being able to trigger assembly/verification via jcmd without
>>     exiting,?would make this far easier for?us to support.
>>
>> There is a proposed enhancement for doing exactly this (and exploring 
>> other ways to trigger end of training run); see 
>> https://bugs.openjdk.org/browse/JDK-8335358
>
>
> I am working on a prototype for dumping with jcmd. It will be similar 
> to the existing "jcmd VM.cds statoc_dump" command, except that it will 
> also support the dumping of the AOT cache and profile data.
>
>
> Thanks
>
> - Ioi
>
>
>>
>> Thanks,
>> - Ashutosh Mehra
>>
>>
>> On Fri, Aug 9, 2024 at 4:38?PM Danny Thomas <dannyt at netflix.com> 
>> wrote:
>>
>>     I tried?24-leydenpremain+2-8 on a few internal applications, 
>> some
>>     quick feedback below (good to see you folks at the JVM LS!).
>>
>>     If a jar has a Class-Path attribute and?one or more of those
>>     libraries are explicitly on the classpath, it causes the actual
>>     and expected classpath to always differ. This is also the case
>>     currently with CDS of course, but this feature is sure to be
>>     deployed far more broadly than CDS is currently, so likely
>>     something you want to look at:
>>
>>     [0.057s][info][class,path] non-existent Class-Path entry
>>     lib/failureaccess-1.0.1.jar
>>     [0.057s][info][class,path] opened:
>>     lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
>>     [0.057s][info][class,path] library =
>>     lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
>>
>>     Startup time when training seems to be on par
>>     with?ArchiveClassesAtExit in JDK 21, but it's?about a 3.5x 
>> startup
>>     time penalty for one of our typical Spring Boot applications. 
>> From
>>     a back-to-back run on my machine (AMD EPYC 9R14, 32 cores, 123G,
>>     Ubuntu 22.04.4 LTS):
>>
>>     Started App in 7.698 seconds (process running for 8.229)
>>     Started App in 26.247 seconds (process running for 29.262) - w/
>>     CacheDataStore, Training Run
>>     Started App in 4.341 seconds (process running for 4.917)??- w/
>>     CacheDataStore, Production Run
>>
>>     I also got a crash on one attempt, I can't remember what I did to
>>     cause this unfortunately:
>>
>>     Stack: [0x00007f3949ab0000,0x00007f3949bb0000],
>>     ?sp=0x00007f3949bae628, ?free space=1017k
>>     Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>     C=native code)
>>     V ?[libjvm.so+0x42ca30]
>>     ?ArchiveBuilder::get_buffered_addr(unsigned char*) const+0x40
>>     V ?[libjvm.so+0xce4aa5] 
>> ?VM_PopulateDumpSharedSpace::doit()+0x395
>>     V ?[libjvm.so+0x100ae69] ?VM_Operation::evaluate()+0x109
>>     V ?[libjvm.so+0x100e348]
>>     ?VMThread::evaluate_operation(VM_Operation*)+0xe8
>>     V ?[libjvm.so+0x10142fb] 
>> ?VMThread::inner_execute(VM_Operation*)+0x35b
>>     V ?[libjvm.so+0x101460f] ?VMThread::run()+0x16f
>>     V ?[libjvm.so+0xf6e5cf] ?Thread::call_run()+0x9f
>>     V ?[libjvm.so+0xd74e13] ?thread_native_entry(Thread*)+0x183
>>     C ?[libc.so.6+0x98b07]
>>
>>     siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR),
>>     si_addr: 0x0000000000000030
>>
>>     Thinking ahead to operationalizing AOT, while a
>>     single-shot/on-exit workflow is great for iterating locally,
>>     requiring the VM to exit makes this more difficult to
>>     operationalize at scale:
>>
>>      1. We'll perform training and assembly on test, production 
>> canary
>>         and production instances on behalf of application owners and
>>         handle distribution of the archives. Depending on when we're
>>         able to perform a training run, it'll have different 
>> benefits.
>>         i.e.:
>>          1. Test environment will at least improve startup
>>             performance, with a mixed benefit for warm up depending 
>> on
>>             the kind of traffic they take in test
>>          2. If an application uses canary deployments we'll have a
>>             full production profile prior to the full production
>>             deployment, and all instances will come up hot
>>          3. If we reach production with only a test environment
>>             profile, we'll perform a training run in production, so
>>             instances that scale up following that run will come up
>>             hot (completely cold instances for an initial deployment
>>             is less of a concern, because we deploy immutably and get
>>             a natural warm-up period while we have 200% capacity
>>             online for a cluster)
>>      2. It's currently not a problem if a VM doesn't exit completely
>>         due to a dangling non-daemon thread or hung shutdown hook
>>
>>     Being able to trigger assembly/verification via jcmd without
>>     exiting,?would make this far easier for?us to support. If the
>>     overhead of the instrumentation for CDS can?be avoided, being 
>> able
>>     to take a snapshot at any time on any VM would be better still,
>>     but that wouldn't be an impediment for us:?we'll know that the
>>     instance will be used for training at boot time.
>>
>>     We build nightlies of all the currently active OpenJDK projects,
>>     so if you land anything on premain between EA builds that you'd
>>     like us to try, let us know!
>>
>>     Cheers,
>>     Danny
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240816/ce093c76/attachment.htm>

From shipilev at amazon.de  Mon Aug 19 08:52:32 2024
From: shipilev at amazon.de (Aleksey Shipilev)
Date: Mon, 19 Aug 2024 10:52:32 +0200
Subject: Enabling clean PRs in Leyden
In-Reply-To: <70a7b55d-f286-4a85-9585-77b791160403@amazon.de>
References: <70a7b55d-f286-4a85-9585-77b791160403@amazon.de>
Message-ID: <e52cf012-9586-4e67-af2e-253c34711761@amazon.de>

Hi again,

On 15.08.24 23:47, Aleksey Shipilev wrote:
> 1. Enable Skara bots to show GHA results:
>  ?https://bugs.openjdk.org/browse/SKARA-2353

Still waiting on this one to resolve. I poked ErikJ, maybe this will help.

> 2. jcheck configuration for the repository:
>  ?https://github.com/openjdk/leyden/pull/11

This one is merged by Ioi, thanks!

> 3. Code changes to make most (all?) builds clean:
>  ?(this one is progress, I need to confirm all GHA jobs are green)
>  ?https://github.com/openjdk/leyden/pull/10

This progresses nicely, and needs another thing: a merge from current openjdk mainline, so that we 
get x86_32 test jobs disabled (https://bugs.openjdk.org/browse/JDK-8338286).

Besides that, there are two DeterministicDump test failures on macos-x64 and windows-x64. 
Interestingly, there is no test failure on macos-aarch64, linux-aarch64, or linux-x64. I have not 
looked into that in any detail, maybe someone knows what is up with those:

Fails like this:

----------System.err:(12/677)----------
java.lang.RuntimeException: File content different at byte #4, b0 = -92, b1 = 113
	at DeterministicDump.compare(DeterministicDump.java:114)
	at DeterministicDump.doTest(DeterministicDump.java:66)
	at DeterministicDump.main(DeterministicDump.java:46)
	at 
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:588)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1575)

Example:
   https://github.com/shipilev/leyden/actions/runs/10415862715

-Aleksey



Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

From mr at openjdk.org  Mon Aug 19 15:26:23 2024
From: mr at openjdk.org (Mark Reinhold)
Date: Mon, 19 Aug 2024 15:26:23 GMT
Subject: git: openjdk/leyden: premain: Update JEP titles,
 and add a general warning that flags will be renamed
Message-ID: <c4ea30c8-a3d0-4c34-b0db-089c8695de5c@openjdk.org>

Changeset: 864228c7
Branch: premain
Author:    Mark Reinhold <mr at openjdk.org>
Date:      2024-08-15 18:07:06 +0000
URL:       https://git.openjdk.org/leyden/commit/864228c7c494e7d46ab653eaacaacb8169dd34df

Update JEP titles, and add a general warning that flags will be renamed

! README.md


From mr at openjdk.org  Mon Aug 19 15:28:38 2024
From: mr at openjdk.org (Mark Reinhold)
Date: Mon, 19 Aug 2024 15:28:38 GMT
Subject: git: openjdk/leyden: leyden-ea1-release-notes: Update JEP titles,
 and add a general warning that flags will be renamed
Message-ID: <c7dc6e03-66fb-45bc-bfb3-573603ae063c@openjdk.org>

Changeset: 6f84e96b
Branch: leyden-ea1-release-notes
Author:    Mark Reinhold <mr at openjdk.org>
Date:      2024-08-15 17:21:10 +0000
URL:       https://git.openjdk.org/leyden/commit/6f84e96b7be30c2ad3ccb6db18610f0bcf92e167

Update JEP titles, and add a general warning that flags will be renamed

! README.md


From ioi.lam at oracle.com  Mon Aug 19 19:29:27 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Mon, 19 Aug 2024 12:29:27 -0700
Subject: Enabling clean PRs in Leyden
In-Reply-To: <e52cf012-9586-4e67-af2e-253c34711761@amazon.de>
References: <70a7b55d-f286-4a85-9585-77b791160403@amazon.de>
 <e52cf012-9586-4e67-af2e-253c34711761@amazon.de>
Message-ID: <855c4c24-d65a-4a1a-a231-8f51ef7a3187@oracle.com>

>> 3. Code changes to make most (all?) builds clean:
>> ??(this one is progress, I need to confirm all GHA jobs are green)
>> ??https://github.com/openjdk/leyden/pull/10
>
> This progresses nicely, and needs another thing: a merge from current 
> openjdk mainline, so that we get x86_32 test jobs disabled 
> (https://bugs.openjdk.org/browse/JDK-8338286).
>
> Besides that, there are two DeterministicDump test failures on 
> macos-x64 and windows-x64. Interestingly, there is no test failure on 
> macos-aarch64, linux-aarch64, or linux-x64. I have not looked into 
> that in any detail, maybe someone knows what is up with those:
>
I am working on Windows failures now (e.g., JDK-8338604) and I've seen 
this also. If I have time I'll take a look at the deterministic dump, 
but it would be low priority.

Thanks

- Ioi


> Fails like this:
>
> ----------System.err:(12/677)----------
> java.lang.RuntimeException: File content different at byte #4, b0 = 
> -92, b1 = 113
> ????at DeterministicDump.compare(DeterministicDump.java:114)
> ????at DeterministicDump.doTest(DeterministicDump.java:66)
> ????at DeterministicDump.main(DeterministicDump.java:46)
> ????at 
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> ????at java.base/java.lang.reflect.Method.invoke(Method.java:588)
> ????at 
> com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
> ????at java.base/java.lang.Thread.run(Thread.java:1575)
>
> Example:
> ? https://github.com/shipilev/leyden/actions/runs/10415862715
>
> -Aleksey

From duke at openjdk.org  Tue Aug 20 03:29:13 2024
From: duke at openjdk.org (duke)
Date: Tue, 20 Aug 2024 03:29:13 GMT
Subject: git: openjdk/leyden: premain: 2 new changesets
Message-ID: <71b2eb7f-a91c-43f3-9b47-00295ce1a6b6@openjdk.org>

Changeset: a5daf90b
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-19 13:29:36 +0000
URL:       https://git.openjdk.org/leyden/commit/a5daf90b0e818194fd11e74569e72f6dc70c105c

Fixed runtime/cds/DeterministicDump.java failure on Windows

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

Changeset: 1ee287c0
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-19 20:25:59 +0000
URL:       https://git.openjdk.org/leyden/commit/1ee287c0677c430b956324691c6751cbeaf64aaa

(1) Fixed Windows failures; (2) Clean up use of CDSConfig::is_xxx(); (3) Consolidate SpringPetClinic.java tests

! src/hotspot/share/cds/aotConstantPoolResolver.cpp
! src/hotspot/share/cds/cdsConfig.cpp
! src/hotspot/share/cds/cdsConfig.hpp
! src/hotspot/share/cds/finalImageRecipes.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/classfile/modules.cpp
! src/hotspot/share/prims/jvm.cpp
! test/hotspot/jtreg/ProblemList-premain.txt
! test/hotspot/jtreg/runtime/cds/appcds/applications/HelidonQuickStartSE.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/MicronautFirstApp.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/QuarkusGettingStarted.java
+ test/hotspot/jtreg/runtime/cds/appcds/applications/SpringPetClinic.java
- 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/LeydenGCFlags.java


From dannyt at netflix.com  Tue Aug 20 05:26:29 2024
From: dannyt at netflix.com (Danny Thomas)
Date: Tue, 20 Aug 2024 15:26:29 +1000
Subject: EA feedback
In-Reply-To: <91d5033c-7c0d-4670-8b38-b801dd2ceea1@oracle.com>
References: <CAABjz10oAmoLkEfLSLo0MN7+BzCFQJ5VYSkmhWH6GB6SVrF57Q@mail.gmail.com>
 <91d5033c-7c0d-4670-8b38-b801dd2ceea1@oracle.com>
Message-ID: <CAABjz11pXCGb3GDaONz_den7UHUwdBK11+6bBFBwLURK0B=Ktw@mail.gmail.com>

I created a reduced version of what we're seeing here:

https://gist.github.com/DanielThomas/83eefaad41af33a071d9a9ee17ca8fe1


On Tue, Aug 13, 2024 at 1:54?PM Calvin Cheung <calvin.cheung at oracle.com>
wrote:

> Hi Danny,
> On 8/9/24 1:38 PM, Danny Thomas wrote:
>
> I tried 24-leydenpremain+2-8 on a few internal applications, some quick
> feedback below (good to see you folks at the JVM LS!).
>
> Thanks for trying the EA build.
>
>
> If a jar has a Class-Path attribute and one or more of those libraries are
> explicitly on the classpath, it causes the actual and expected classpath to
> always differ. This is also the case currently with CDS of course, but this
> feature is sure to be deployed far more broadly than CDS is currently, so
> likely something you want to look at:
>
> [0.057s][info][class,path] non-existent Class-Path entry
> lib/failureaccess-1.0.1.jar
> [0.057s][info][class,path] opened:
> lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
> [0.057s][info][class,path] library =
> lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
>
> I couldn't reproduce the above Class-Path attribute issue with a simple
> test[1]. The simple test was extracted from an existing test case[2].
>
> Can you provide a test case?
>
> (I'll let others to answer the other issues.)
> Thanks,
> Calvin
> [1] https://cr.openjdk.org/~ccheung/cp-attribute/
> [2]
> https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/cds/appcds/ClassPathAttr.java
>
>
> Startup time when training seems to be on par with ArchiveClassesAtExit in
> JDK 21, but it's about a 3.5x startup time penalty for one of our typical
> Spring Boot applications. From a back-to-back run on my machine (AMD EPYC
> 9R14, 32 cores, 123G, Ubuntu 22.04.4 LTS):
>
> Started App in 7.698 seconds (process running for 8.229)
> Started App in 26.247 seconds (process running for 29.262) - w/
> CacheDataStore, Training Run
> Started App in 4.341 seconds (process running for 4.917)  - w/
> CacheDataStore, Production Run
>
> I also got a crash on one attempt, I can't remember what I did to cause
> this unfortunately:
>
> Stack: [0x00007f3949ab0000,0x00007f3949bb0000],  sp=0x00007f3949bae628,
>  free space=1017k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V  [libjvm.so+0x42ca30]  ArchiveBuilder::get_buffered_addr(unsigned char*)
> const+0x40
> V  [libjvm.so+0xce4aa5]  VM_PopulateDumpSharedSpace::doit()+0x395
> V  [libjvm.so+0x100ae69]  VM_Operation::evaluate()+0x109
> V  [libjvm.so+0x100e348]  VMThread::evaluate_operation(VM_Operation*)+0xe8
> V  [libjvm.so+0x10142fb]  VMThread::inner_execute(VM_Operation*)+0x35b
> V  [libjvm.so+0x101460f]  VMThread::run()+0x16f
> V  [libjvm.so+0xf6e5cf]  Thread::call_run()+0x9f
> V  [libjvm.so+0xd74e13]  thread_native_entry(Thread*)+0x183
> C  [libc.so.6+0x98b07]
>
> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
> 0x0000000000000030
>
> Thinking ahead to operationalizing AOT, while a single-shot/on-exit
> workflow is great for iterating locally, requiring the VM to exit makes
> this more difficult to operationalize at scale:
>
>    1. We'll perform training and assembly on test, production canary and
>    production instances on behalf of application owners and handle
>    distribution of the archives. Depending on when we're able to perform a
>    training run, it'll have different benefits. i.e.:
>       1. Test environment will at least improve startup performance, with
>       a mixed benefit for warm up depending on the kind of traffic they take in
>       test
>       2. If an application uses canary deployments we'll have a full
>       production profile prior to the full production deployment, and all
>       instances will come up hot
>       3. If we reach production with only a test environment profile,
>       we'll perform a training run in production, so instances that scale up
>       following that run will come up hot (completely cold instances for an
>       initial deployment is less of a concern, because we deploy immutably and
>       get a natural warm-up period while we have 200% capacity online for a
>       cluster)
>    2. It's currently not a problem if a VM doesn't exit completely due to
>    a dangling non-daemon thread or hung shutdown hook
>
> Being able to trigger assembly/verification via jcmd without
> exiting, would make this far easier for us to support. If the overhead of
> the instrumentation for CDS can be avoided, being able to take a snapshot
> at any time on any VM would be better still, but that wouldn't be an
> impediment for us: we'll know that the instance will be used for training
> at boot time.
>
> We build nightlies of all the currently active OpenJDK projects, so if you
> land anything on premain between EA builds that you'd like us to try, let
> us know!
>
> Cheers,
> Danny
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240820/e285817b/attachment.htm>

From adinn at redhat.com  Tue Aug 20 14:11:43 2024
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 20 Aug 2024 15:11:43 +0100
Subject: [External] : Re: premain: Possible solutions to use runtime G1
 region grain size in AOT code (JDK-8335440)
In-Reply-To: <0916b5e3-3d5f-40bd-94b2-9eb01f600c60@oracle.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>
 <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>
 <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>
 <84057040-3d3a-48be-88b3-502205ee6a7d@oracle.com>
 <a231c010-9fbc-485c-8e6e-6e8040524889@redhat.com>
 <b2f3983a-d6fa-4a07-a742-9e0c4a59e88d@oracle.com>
 <5e931bd6-c766-4939-b338-c60594b5e665@redhat.com>
 <5257f86c-2910-45c3-972f-929494fb3267@oracle.com>
 <3db5a5f3-41c3-4cfa-b446-273af5625ac1@redhat.com>
 <594256c5-b81d-453d-a4f4-6165b8368a9e@oracle.com>
 <CAKt0pyTjmXhXhk9snL3-D-qJo_S_H5c0A6HyxPkYcBSXR7jbLw@mail.gmail.com>
 <fdad55a9-50af-42c8-8a6a-f9f91a1a72f6@oracle.com>
 <17da0ba4-1934-4f4f-804e-2a4ba6cef45e@redhat.com>
 <aa1679da-183a-480b-ac1e-9739c7198215@oracle.com>
 <CAKt0pyTGPpm5Qo2PmuoPiTdZaUTGas4XRYYdt=0Wf_eFSVWVgw@mail.gmail.com>
 <e855be08-53f8-4825-959d-81f9016f5802@oracle.com>
 <0916b5e3-3d5f-40bd-94b2-9eb01f600c60@oracle.com>
Message-ID: <7ea00fac-d289-4d55-a7d0-0ed9aa3ad272@redhat.com>

On 15/08/2024 23:30, Vladimir Kozlov wrote:

>> Why you still use base+offsets for constants address? Is it for Aarch64?
>>
>> What I want is something like this:
>>
>> static address grain_shift_address() { return 
>> &_aot_runtime_constants::_grain_shift; }

Hmm, I thought I had made the changes to use a direct address but they 
were not in the aarch64 version I pushed. I have pushed a new version 
that fixes the macroassembler and g1 stubs to load the field address as 
a constant. I removed the xxx_offset() methods from AOTRuntimeConstants 
and replaced them with xxx_address() methods to make sure it can only be 
done that way.

>> And you will not need `#if INCLUDE_CDS` if you put AOTRuntimeConstants 
>> into SCCache.cpp.

Yes, SCCache.hpp/cpp is a much better place for this class than 
stubRoutines.hpp/cpp. The need to generate AOT code variants that employ 
constants from the current runtime is not specific to stubGenerator 
stubs. However, it always relates to use of the AOT cache.

>> I don't see the need to separate create_field_address_list() code from 
>> field_addresses_list().

Sorry, this was a hangover from an initial implementation. The getter 
now returns the array from a static field initialized in SCCache.cpp.

>> Add assert to field_addresses_list() to check that values are 
>> initialized.
> 
> Actually you don't need assert since we need only addresses of fields.

Left as is.

> I don't see use of aot_runtime_constants_at() anymore.

It is redundant and has been removed.

> Also why you need aot_runtime_constants()? Why not have 
> _aot_runtime_constants as static field of AOTRuntimeConstants class 
> which you can initialize in (again) SCCache.cpp?
Agreed. The static singleton is now only used internally to the class. 
So, we no longer need aot_runtime_constants() any more.

Latest code:

 
https://github.com/adinn/leyden/compare/premain...adinn:leyden:JDK-8335440-load-via-codecache?expand=1

This passes tier1 tests on aarch64 and successfully improves performance 
for the javac benchmark.

regards,


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


From ioi.lam at oracle.com  Tue Aug 20 15:45:23 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Tue, 20 Aug 2024 08:45:23 -0700
Subject: Enabling clean PRs in Leyden
In-Reply-To: <855c4c24-d65a-4a1a-a231-8f51ef7a3187@oracle.com>
References: <70a7b55d-f286-4a85-9585-77b791160403@amazon.de>
 <e52cf012-9586-4e67-af2e-253c34711761@amazon.de>
 <855c4c24-d65a-4a1a-a231-8f51ef7a3187@oracle.com>
Message-ID: <45050708-b379-4fab-96b6-073f1af2da08@oracle.com>


On 8/19/24 12:29 PM, ioi.lam at oracle.com wrote:
>>> 3. Code changes to make most (all?) builds clean:
>>> ??(this one is progress, I need to confirm all GHA jobs are green)
>>> ??https://github.com/openjdk/leyden/pull/10
>>
>> This progresses nicely, and needs another thing: a merge from current 
>> openjdk mainline, so that we get x86_32 test jobs disabled 
>> (https://bugs.openjdk.org/browse/JDK-8338286).
>>
>> Besides that, there are two DeterministicDump test failures on 
>> macos-x64 and windows-x64. Interestingly, there is no test failure on 
>> macos-aarch64, linux-aarch64, or linux-x64. I have not looked into 
>> that in any detail, maybe someone knows what is up with those:
>>
> I am working on Windows failures now (e.g., JDK-8338604) and I've seen 
> this also. If I have time I'll take a look at the deterministic dump, 
> but it would be low priority.
>

The problem with deterministic build is fixed in this commit

https://github.com/openjdk/leyden/commit/a5daf90b0e818194fd11e74569e72f6dc70c105c


> Thanks
>
> - Ioi
>
>
>> Fails like this:
>>
>> ----------System.err:(12/677)----------
>> java.lang.RuntimeException: File content different at byte #4, b0 = 
>> -92, b1 = 113
>> ????at DeterministicDump.compare(DeterministicDump.java:114)
>> ????at DeterministicDump.doTest(DeterministicDump.java:66)
>> ????at DeterministicDump.main(DeterministicDump.java:46)
>> ????at 
>> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>> ????at java.base/java.lang.reflect.Method.invoke(Method.java:588)
>> ????at 
>> com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
>> ????at java.base/java.lang.Thread.run(Thread.java:1575)
>>
>> Example:
>> ? https://github.com/shipilev/leyden/actions/runs/10415862715
>>
>> -Aleksey

From shipilev at amazon.de  Tue Aug 20 15:49:01 2024
From: shipilev at amazon.de (Aleksey Shipilev)
Date: Tue, 20 Aug 2024 17:49:01 +0200
Subject: Enabling clean PRs in Leyden
In-Reply-To: <45050708-b379-4fab-96b6-073f1af2da08@oracle.com>
References: <70a7b55d-f286-4a85-9585-77b791160403@amazon.de>
 <e52cf012-9586-4e67-af2e-253c34711761@amazon.de>
 <855c4c24-d65a-4a1a-a231-8f51ef7a3187@oracle.com>
 <45050708-b379-4fab-96b6-073f1af2da08@oracle.com>
Message-ID: <84f91954-12ee-4f5b-8c13-d816694d565a@amazon.de>

On 20.08.24 17:45, ioi.lam at oracle.com wrote:
> The problem with deterministic build is fixed in this commit
> 
> https://github.com/openjdk/leyden/commit/a5daf90b0e818194fd11e74569e72f6dc70c105c

Yes, I noticed from the commit logs, thanks!

I picked it up already, and GHA runs become clean.

Now we only need the merge from mainline to fix x86_32.

-Aleksey



Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

From calvin.cheung at oracle.com  Tue Aug 20 16:46:59 2024
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Tue, 20 Aug 2024 09:46:59 -0700
Subject: [External] : Re: EA feedback
In-Reply-To: <CAABjz11pXCGb3GDaONz_den7UHUwdBK11+6bBFBwLURK0B=Ktw@mail.gmail.com>
References: <CAABjz10oAmoLkEfLSLo0MN7+BzCFQJ5VYSkmhWH6GB6SVrF57Q@mail.gmail.com>
 <91d5033c-7c0d-4670-8b38-b801dd2ceea1@oracle.com>
 <CAABjz11pXCGb3GDaONz_den7UHUwdBK11+6bBFBwLURK0B=Ktw@mail.gmail.com>
Message-ID: <43b1aa91-7d49-40f0-9137-7922f24c7a0a@oracle.com>


On 8/19/24 10:26 PM, Danny Thomas wrote:
> I created a reduced version of what we're seeing here:
>
> https://gist.github.com/DanielThomas/83eefaad41af33a071d9a9ee17ca8fe1 
> <https://urldefense.com/v3/__https://gist.github.com/DanielThomas/83eefaad41af33a071d9a9ee17ca8fe1__;!!ACWV5N9M2RV99hQ!MtJRHiVk_i583hydhLE7sXfaYzbgUBlQV59Zl9BqWi3iTHM1Wj1EDJ4X0Y_6rZdFtKkLsaHIWRGH3j1PnfA$>
>
>
I could see the problem and filed the following bug:
https://bugs.openjdk.org/browse/JDK-8338686

A workaround is not to include the jars, which are in the Class-Path 
attribute, in the -cp.

The test passed with the following CP setting:

CP="lib/guice-all-5.1.1-jakartaee.jar:lib/main.jar"

Thanks,
Calvin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240820/b7720ae3/attachment.htm>

From vladimir.kozlov at oracle.com  Tue Aug 20 17:35:19 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 20 Aug 2024 10:35:19 -0700
Subject: [External] : Re: premain: Possible solutions to use runtime G1
 region grain size in AOT code (JDK-8335440)
In-Reply-To: <7ea00fac-d289-4d55-a7d0-0ed9aa3ad272@redhat.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>
 <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>
 <84057040-3d3a-48be-88b3-502205ee6a7d@oracle.com>
 <a231c010-9fbc-485c-8e6e-6e8040524889@redhat.com>
 <b2f3983a-d6fa-4a07-a742-9e0c4a59e88d@oracle.com>
 <5e931bd6-c766-4939-b338-c60594b5e665@redhat.com>
 <5257f86c-2910-45c3-972f-929494fb3267@oracle.com>
 <3db5a5f3-41c3-4cfa-b446-273af5625ac1@redhat.com>
 <594256c5-b81d-453d-a4f4-6165b8368a9e@oracle.com>
 <CAKt0pyTjmXhXhk9snL3-D-qJo_S_H5c0A6HyxPkYcBSXR7jbLw@mail.gmail.com>
 <fdad55a9-50af-42c8-8a6a-f9f91a1a72f6@oracle.com>
 <17da0ba4-1934-4f4f-804e-2a4ba6cef45e@redhat.com>
 <aa1679da-183a-480b-ac1e-9739c7198215@oracle.com>
 <CAKt0pyTGPpm5Qo2PmuoPiTdZaUTGas4XRYYdt=0Wf_eFSVWVgw@mail.gmail.com>
 <e855be08-53f8-4825-959d-81f9016f5802@oracle.com>
 <0916b5e3-3d5f-40bd-94b2-9eb01f600c60@oracle.com>
 <7ea00fac-d289-4d55-a7d0-0ed9aa3ad272@redhat.com>
Message-ID: <f5aa9e80-c2ee-4754-9293-59d1a5b842ce@oracle.com>

Yes, this is much better.

Thanks,
Vladimir K

On 8/20/24 7:11 AM, Andrew Dinn wrote:
> On 15/08/2024 23:30, Vladimir Kozlov wrote:
> 
>>> Why you still use base+offsets for constants address? Is it for Aarch64?
>>>
>>> What I want is something like this:
>>>
>>> static address grain_shift_address() { return &_aot_runtime_constants::_grain_shift; }
> 
> Hmm, I thought I had made the changes to use a direct address but they were not in the aarch64 version I pushed. I have 
> pushed a new version that fixes the macroassembler and g1 stubs to load the field address as a constant. I removed the 
> xxx_offset() methods from AOTRuntimeConstants and replaced them with xxx_address() methods to make sure it can only be 
> done that way.
> 
>>> And you will not need `#if INCLUDE_CDS` if you put AOTRuntimeConstants into SCCache.cpp.
> 
> Yes, SCCache.hpp/cpp is a much better place for this class than stubRoutines.hpp/cpp. The need to generate AOT code 
> variants that employ constants from the current runtime is not specific to stubGenerator stubs. However, it always 
> relates to use of the AOT cache.
> 
>>> I don't see the need to separate create_field_address_list() code from field_addresses_list().
> 
> Sorry, this was a hangover from an initial implementation. The getter now returns the array from a static field 
> initialized in SCCache.cpp.
> 
>>> Add assert to field_addresses_list() to check that values are initialized.
>>
>> Actually you don't need assert since we need only addresses of fields.
> 
> Left as is.
> 
>> I don't see use of aot_runtime_constants_at() anymore.
> 
> It is redundant and has been removed.
> 
>> Also why you need aot_runtime_constants()? Why not have _aot_runtime_constants as static field of AOTRuntimeConstants 
>> class which you can initialize in (again) SCCache.cpp?
> Agreed. The static singleton is now only used internally to the class. So, we no longer need aot_runtime_constants() any 
> more.
> 
> Latest code:
> 
> 
> https://urldefense.com/v3/__https://github.com/adinn/leyden/compare/premain...adinn:leyden:JDK-8335440-load-via-codecache?expand=1__;!!ACWV5N9M2RV99hQ!JvSVWm0OpYY_RBUQMwmBhuNFku_mjcqP_anYtWrigTz-Tp1SNf2agHStFtr6FqGYCUNX3LKSRIG3IeE90aw$
> This passes tier1 tests on aarch64 and successfully improves performance for the javac benchmark.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> 

From duke at openjdk.org  Tue Aug 20 18:16:41 2024
From: duke at openjdk.org (duke)
Date: Tue, 20 Aug 2024 18:16:41 GMT
Subject: git: openjdk/leyden: premain: Merged ProblemList-premain.txt into
 ProblemList.txt
Message-ID: <aaf40329-5c0d-4d86-bb63-dc34afd69688@openjdk.org>

Changeset: 7e207bd7
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-20 11:15:39 +0000
URL:       https://git.openjdk.org/leyden/commit/7e207bd757332461d5920c5f8a395da9fdc5d4cf

Merged ProblemList-premain.txt into ProblemList.txt

- test/hotspot/jtreg/ProblemList-premain.txt
! test/hotspot/jtreg/ProblemList.txt


From adinn at redhat.com  Wed Aug 21 12:56:21 2024
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 21 Aug 2024 13:56:21 +0100
Subject: [External] : Re: premain: Possible solutions to use runtime G1
 region grain size in AOT code (JDK-8335440)
In-Reply-To: <f5aa9e80-c2ee-4754-9293-59d1a5b842ce@oracle.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>
 <84057040-3d3a-48be-88b3-502205ee6a7d@oracle.com>
 <a231c010-9fbc-485c-8e6e-6e8040524889@redhat.com>
 <b2f3983a-d6fa-4a07-a742-9e0c4a59e88d@oracle.com>
 <5e931bd6-c766-4939-b338-c60594b5e665@redhat.com>
 <5257f86c-2910-45c3-972f-929494fb3267@oracle.com>
 <3db5a5f3-41c3-4cfa-b446-273af5625ac1@redhat.com>
 <594256c5-b81d-453d-a4f4-6165b8368a9e@oracle.com>
 <CAKt0pyTjmXhXhk9snL3-D-qJo_S_H5c0A6HyxPkYcBSXR7jbLw@mail.gmail.com>
 <fdad55a9-50af-42c8-8a6a-f9f91a1a72f6@oracle.com>
 <17da0ba4-1934-4f4f-804e-2a4ba6cef45e@redhat.com>
 <aa1679da-183a-480b-ac1e-9739c7198215@oracle.com>
 <CAKt0pyTGPpm5Qo2PmuoPiTdZaUTGas4XRYYdt=0Wf_eFSVWVgw@mail.gmail.com>
 <e855be08-53f8-4825-959d-81f9016f5802@oracle.com>
 <0916b5e3-3d5f-40bd-94b2-9eb01f600c60@oracle.com>
 <7ea00fac-d289-4d55-a7d0-0ed9aa3ad272@redhat.com>
 <f5aa9e80-c2ee-4754-9293-59d1a5b842ce@oracle.com>
Message-ID: <c6bbf69f-97d3-4bb5-be82-d134ab4ad833@redhat.com>

On 20/08/2024 18:35, Vladimir Kozlov wrote:
> Yes, this is much better.

Ok, thanks. I'll push this into the premain branch.

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill

> On 8/20/24 7:11 AM, Andrew Dinn wrote:
>> On 15/08/2024 23:30, Vladimir Kozlov wrote:
>>
>>>> Why you still use base+offsets for constants address? Is it for 
>>>> Aarch64?
>>>>
>>>> What I want is something like this:
>>>>
>>>> static address grain_shift_address() { return 
>>>> &_aot_runtime_constants::_grain_shift; }
>>
>> Hmm, I thought I had made the changes to use a direct address but they 
>> were not in the aarch64 version I pushed. I have pushed a new version 
>> that fixes the macroassembler and g1 stubs to load the field address 
>> as a constant. I removed the xxx_offset() methods from 
>> AOTRuntimeConstants and replaced them with xxx_address() methods to 
>> make sure it can only be done that way.
>>
>>>> And you will not need `#if INCLUDE_CDS` if you put 
>>>> AOTRuntimeConstants into SCCache.cpp.
>>
>> Yes, SCCache.hpp/cpp is a much better place for this class than 
>> stubRoutines.hpp/cpp. The need to generate AOT code variants that 
>> employ constants from the current runtime is not specific to 
>> stubGenerator stubs. However, it always relates to use of the AOT cache.
>>
>>>> I don't see the need to separate create_field_address_list() code 
>>>> from field_addresses_list().
>>
>> Sorry, this was a hangover from an initial implementation. The getter 
>> now returns the array from a static field initialized in SCCache.cpp.
>>
>>>> Add assert to field_addresses_list() to check that values are 
>>>> initialized.
>>>
>>> Actually you don't need assert since we need only addresses of fields.
>>
>> Left as is.
>>
>>> I don't see use of aot_runtime_constants_at() anymore.
>>
>> It is redundant and has been removed.
>>
>>> Also why you need aot_runtime_constants()? Why not have 
>>> _aot_runtime_constants as static field of AOTRuntimeConstants class 
>>> which you can initialize in (again) SCCache.cpp?
>> Agreed. The static singleton is now only used internally to the class. 
>> So, we no longer need aot_runtime_constants() any more.
>>
>> Latest code:
>>
>>
>> https://urldefense.com/v3/__https://github.com/adinn/leyden/compare/premain...adinn:leyden:JDK-8335440-load-via-codecache?expand=1__;!!ACWV5N9M2RV99hQ!JvSVWm0OpYY_RBUQMwmBhuNFku_mjcqP_anYtWrigTz-Tp1SNf2agHStFtr6FqGYCUNX3LKSRIG3IeE90aw$
>> This passes tier1 tests on aarch64 and successfully improves 
>> performance for the javac benchmark.
>>
>> regards,
>>
>>
>> Andrew Dinn
>> -----------
>>
> 


From duke at openjdk.org  Wed Aug 21 15:14:59 2024
From: duke at openjdk.org (duke)
Date: Wed, 21 Aug 2024 15:14:59 GMT
Subject: git: openjdk/leyden: premain: 2 new changesets
Message-ID: <70392e01-d753-43c6-b190-3c06523c1276@openjdk.org>

Changeset: cb30dfbb
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-20 14:10:00 +0000
URL:       https://git.openjdk.org/leyden/commit/cb30dfbb8809647dc0b86612b09d3a320e7fdf5d

Renamed -XX:+ArchiveInvokeDynamic to -XX:+AOTInvokeDynamicLinking, and changed to a diagnostic flag

! README.md
! src/hotspot/share/cds/cdsConfig.cpp
! src/hotspot/share/cds/cdsConfig.hpp
! src/hotspot/share/cds/cds_globals.hpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/filemap.hpp
! test/hotspot/jtreg/premain/InvokeDynamic.md
! test/hotspot/jtreg/premain/javac_new_workflow/README.md
! test/hotspot/jtreg/premain/javac_new_workflow/run.sh
! test/hotspot/jtreg/premain/lib/bench-lib-new-workflow.sh
! test/hotspot/jtreg/premain/lib/bench-lib.sh
! test/hotspot/jtreg/premain/spring-petclinic/Makefile
! test/hotspot/jtreg/premain/spring-petclinic/WarmupMakefile
! test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java
! test/hotspot/jtreg/runtime/cds/appcds/indy/IndyTestBase.java
! test/hotspot/jtreg/runtime/cds/appcds/indy/StringConcatStress2.java
! test/lib/jdk/test/lib/cds/CDSAppTester.java

Changeset: 641fdabf
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-20 22:16:58 +0000
URL:       https://git.openjdk.org/leyden/commit/641fdabf083ea8b9a46fcd92191482e29cf9d2a5

More clean up of -XX:+AOTInvokeDynamicLinking before upstreaming to mainline

! src/hotspot/share/cds/cdsConfig.cpp
! src/hotspot/share/cds/cdsConfig.hpp
! src/hotspot/share/cds/cdsHeapVerifier.cpp
! src/hotspot/share/cds/dumpTimeClassInfo.cpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/interpreter/interpreterRuntime.hpp
! src/hotspot/share/oops/constantPool.cpp
! src/hotspot/share/prims/jvm.cpp
! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
! src/java.base/share/classes/java/lang/invoke/LambdaForm.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleStatics.java
! src/java.base/share/classes/java/lang/invoke/MethodType.java
! src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java


From duke at openjdk.org  Wed Aug 21 16:22:39 2024
From: duke at openjdk.org (duke)
Date: Wed, 21 Aug 2024 16:22:39 GMT
Subject: git: openjdk/leyden: premain: AOT G1 barrier loads region grain and
 card shifts via runtime constants data area
Message-ID: <f54e5b7f-25b0-4631-817c-293cab29367a@openjdk.org>

Changeset: c319a3ee
Branch: premain
Author:    Andrew Dinn <adinn at redhat.com>
Date:      2024-08-21 14:48:22 +0000
URL:       https://git.openjdk.org/leyden/commit/c319a3ee2be0236feab88c9be66d71e6e93b53fc

AOT G1 barrier loads region grain and card shifts via runtime constants data area

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/ci/ciUtilities.cpp
! src/hotspot/share/ci/ciUtilities.hpp
! src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/code/SCCache.hpp
! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp
! src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp
! src/hotspot/share/gc/g1/g1BarrierSet.hpp
! src/hotspot/share/gc/shared/barrierSet.hpp
! src/hotspot/share/gc/shared/cardTableBarrierSet.hpp
! src/hotspot/share/runtime/stubRoutines.cpp
! src/hotspot/share/runtime/stubRoutines.hpp


From Matthew.Carter at microsoft.com  Thu Aug 22 16:03:55 2024
From: Matthew.Carter at microsoft.com (Mat Carter)
Date: Thu, 22 Aug 2024 16:03:55 +0000
Subject: EA feedback
In-Reply-To: <A0C193BF-B8DB-4BC6-95D5-BBA21DC92F27@oracle.com>
References: <CAABjz10oAmoLkEfLSLo0MN7+BzCFQJ5VYSkmhWH6GB6SVrF57Q@mail.gmail.com>
 <CAKt0pySHtZHSk0FyarM7kkdygTBppHBcYfpXPOfiJuS+7qjQyg@mail.gmail.com>
 <bcf26ac8-663f-4b11-abb3-1ca942d506e2@oracle.com>
 <A0C193BF-B8DB-4BC6-95D5-BBA21DC92F27@oracle.com>
Message-ID: <BL4PR21MB41283FFEC5120462CF5129368A8F2@BL4PR21MB4128.namprd21.prod.outlook.com>

Having considered the JBS issue [1], we'd like to propose/discuss some additional options, the thought being that while implementation can be staggered it might be helpful to consider them now to help prioritize/rethink/reject.

In summary we currently have the "stop" action, stopping is immediate (now) and operationalized via the following mechanisms:
??????? Ctrl-Z/D
??????? System.Exit()
??????? Run to completion (normal termination)
??????? Unhandled exception :)

And this new ask in JBS [1] is to
??????? Add a mechanism using 'jcmd' and/or a new Leyden API to action the existing "stop" (now) functionality
??????? Add a variant of the "stop" action where training stops when execution enters a java method (optionally after N invocations); specify method to stop on via Command Line (-XX), JCmd and/or Leyden API

We?d like to propose two additional variants to aid with stopping training runs:
??????? Stop training after some time has elapsed
??????? Stop training when some threshold is met

The second point comes from considering the definition of 'startup complete' and 'warmup complete'.  Considering the developer is already engaged in AOT training, we should allow the developer to aid the training by:
??????? Indicating when the application has completed startup (ready to work)
??????? Indicate when the application has completed warmup, either by:
????????????? Calling an API to indicate warmup is done
????????????? Calling an API when a chunk of work has completed, passing in the 'duration'; this 'duration' is compared to some specified 'threshold' to generate the 'warmup is complete' event

Adding a threshold means that training runs can be of optimal length and can handle changes in the environment and/or code.  Coupled with maybe an "abort training" action we now have a training run that targets a threshold and aborts if not reached in time N.

Currently we have the command line, jcmd and a new Leyden API to support training runs.  Lastly we'd like to propose a fourth method that being an MxBean (uses the new Leyden API); this would allow the developer to provide the startup and warmup indicators internally or externally (their choice), and would allow for runtime analysis using bespoke production systems or JMC, and offline analysis via JFR.

Cheers
Mat

[1] https://bugs.openjdk.org/browse/JDK-8335358

From: leyden-dev <leyden-dev-retn at openjdk.org> on behalf of John Rose <john.r.rose at oracle.com>
Date: Friday, August 16, 2024 at 4:51 PM
To: ioi.lam at oracle.com <ioi.lam at oracle.com>
Cc: leyden-dev at openjdk.org <leyden-dev at openjdk.org>
Subject: Re: EA feedback


Here?s the way I would prefer to think about a ?dump command?.

The native way that the JVM represents sequential operations is
the method. Talking about methods is therefore a basic way to
specify a condition for injecting a JVM operation like training
dumps. I would like to figure out a good way to tie the training
dump to the invocation of a method, either a single well-known
method, or to a method specified (on the command line) by the
user.

In fact, it feels like a breakpoint-like operation would be a
natural way to view the training dump. You don?t need JVMTI
to get it done; you just need a hack in the VM which parallels
the existing breakpoint mechanism, but special-cases it to
drive a training dump.

Given such a foundation, jsig could then inject a call to a
method which is appropriately tied to the dump command.

Sketch of implementation:

When a method is first linked, a list is checked to see if
it has a dump event tied to it, and a bit is set on the method.
The method?s interpreter entry point might be modified, or
perhaps the interpreter just always checks the bit. On entry
to the method, before the first bytecode, an upcall tells
the VM that it?s time to finish the training run.

The compilers also check this bit, of course.

There is some method deep in the privates of java.base
that is always treated this way. That?s what jcmd reaches.
There is a command line option which lists more methods
to treat this way, something like the CompileOnly command.

As a separate option, the upcall to end the training run
might return (allowing the VM to continue) or just exit.

As a separate option, allow the user to specify a count N,
so that the training dump happens only after N ?hits? on
any marked method(s).

I think all this is useful and flexible.

On 13 Aug 2024, at 18:22, ioi.lam at oracle.com wrote:


On 8/13/24 12:42 PM, Ashutosh Mehra wrote:
Being able to trigger assembly/verification via jcmd without exiting, would make this far easier for us to support.

There is a proposed enhancement for doing exactly this (and exploring other ways to trigger end of training run); see https://bugs.openjdk.org/browse/JDK-8335358


I am working on a prototype for dumping with jcmd. It will be similar to the existing "jcmd VM.cds statoc_dump" command, except that it will also support the dumping of the AOT cache and profile data.


Thanks

- Ioi


Thanks,
- Ashutosh Mehra


On Fri, Aug 9, 2024 at 4:38?PM Danny Thomas <dannyt at netflix.com<mailto:dannyt at netflix.com>> wrote:
I tried 24-leydenpremain+2-8 on a few internal applications, some quick feedback below (good to see you folks at the JVM LS!).

If a jar has a Class-Path attribute and one or more of those libraries are explicitly on the classpath, it causes the actual and expected classpath to always differ. This is also the case currently with CDS of course, but this feature is sure to be deployed far more broadly than CDS is currently, so likely something you want to look at:

[0.057s][info][class,path] non-existent Class-Path entry lib/failureaccess-1.0.1.jar
[0.057s][info][class,path] opened: lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
[0.057s][info][class,path] library = lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar

Startup time when training seems to be on par with ArchiveClassesAtExit in JDK 21, but it's about a 3.5x startup time penalty for one of our typical Spring Boot applications. From a back-to-back run on my machine (AMD EPYC 9R14, 32 cores, 123G, Ubuntu 22.04.4 LTS):

Started App in 7.698 seconds (process running for 8.229)
Started App in 26.247 seconds (process running for 29.262) - w/ CacheDataStore, Training Run
Started App in 4.341 seconds (process running for 4.917)  - w/ CacheDataStore, Production Run

I also got a crash on one attempt, I can't remember what I did to cause this unfortunately:

Stack: [0x00007f3949ab0000,0x00007f3949bb0000],  sp=0x00007f3949bae628,  free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x42ca30]  ArchiveBuilder::get_buffered_addr(unsigned char*) const+0x40
V  [libjvm.so+0xce4aa5]  VM_PopulateDumpSharedSpace::doit()+0x395
V  [libjvm.so+0x100ae69]  VM_Operation::evaluate()+0x109
V  [libjvm.so+0x100e348]  VMThread::evaluate_operation(VM_Operation*)+0xe8
V  [libjvm.so+0x10142fb]  VMThread::inner_execute(VM_Operation*)+0x35b
V  [libjvm.so+0x101460f]  VMThread::run()+0x16f
V  [libjvm.so+0xf6e5cf]  Thread::call_run()+0x9f
V  [libjvm.so+0xd74e13]  thread_native_entry(Thread*)+0x183
C  [libc.so.6+0x98b07]

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000030

Thinking ahead to operationalizing AOT, while a single-shot/on-exit workflow is great for iterating locally, requiring the VM to exit makes this more difficult to operationalize at scale:

  1.  We'll perform training and assembly on test, production canary and production instances on behalf of application owners and handle distribution of the archives. Depending on when we're able to perform a training run, it'll have different benefits. i.e.:
     *   Test environment will at least improve startup performance, with a mixed benefit for warm up depending on the kind of traffic they take in test
     *   If an application uses canary deployments we'll have a full production profile prior to the full production deployment, and all instances will come up hot
     *   If we reach production with only a test environment profile, we'll perform a training run in production, so instances that scale up following that run will come up hot (completely cold instances for an initial deployment is less of a concern, because we deploy immutably and get a natural warm-up period while we have 200% capacity online for a cluster)
  2.  It's currently not a problem if a VM doesn't exit completely due to a dangling non-daemon thread or hung shutdown hook

Being able to trigger assembly/verification via jcmd without exiting, would make this far easier for us to support. If the overhead of the instrumentation for CDS can be avoided, being able to take a snapshot at any time on any VM would be better still, but that wouldn't be an impediment for us: we'll know that the instance will be used for training at boot time.

We build nightlies of all the currently active OpenJDK projects, so if you land anything on premain between EA builds that you'd like us to try, let us know!

Cheers,
Danny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240822/0d5728d1/attachment.htm>

From duke at openjdk.org  Thu Aug 22 23:10:21 2024
From: duke at openjdk.org (duke)
Date: Thu, 22 Aug 2024 23:10:21 GMT
Subject: git: openjdk/leyden: premain: Enable 1-step workflow with Epsilon GC
Message-ID: <d3b60188-3e11-4dd5-b721-41b3b1c1098a@openjdk.org>

Changeset: 126461c0
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: iklam <ilam3388 at gmail.com>
Date:      2024-08-22 16:07:47 +0000
URL:       https://git.openjdk.org/leyden/commit/126461c0ece1fde43799d669d541e1ca254f0314

Enable 1-step workflow with Epsilon GC

! README.md
! src/hotspot/share/cds/heapShared.hpp
! src/hotspot/share/cds/metaspaceShared.cpp
! test/hotspot/jtreg/runtime/cds/appcds/leyden/LeydenGCFlags.java


From david.holmes at oracle.com  Fri Aug 23 00:09:58 2024
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 23 Aug 2024 10:09:58 +1000
Subject: EA feedback
In-Reply-To: <BL4PR21MB41283FFEC5120462CF5129368A8F2@BL4PR21MB4128.namprd21.prod.outlook.com>
References: <CAABjz10oAmoLkEfLSLo0MN7+BzCFQJ5VYSkmhWH6GB6SVrF57Q@mail.gmail.com>
 <CAKt0pySHtZHSk0FyarM7kkdygTBppHBcYfpXPOfiJuS+7qjQyg@mail.gmail.com>
 <bcf26ac8-663f-4b11-abb3-1ca942d506e2@oracle.com>
 <A0C193BF-B8DB-4BC6-95D5-BBA21DC92F27@oracle.com>
 <BL4PR21MB41283FFEC5120462CF5129368A8F2@BL4PR21MB4128.namprd21.prod.outlook.com>
Message-ID: <8075078b-eeb7-400e-b169-27b8370f8bf4@oracle.com>

I'm normally just a lurker here but wanted to clarify one thing ...

On 23/08/2024 2:03 am, Mat Carter wrote:
> Having considered the JBS issue [1], we'd like to propose/discuss some 
> additional options, the thought being that while implementation can be 
> staggered it might be helpful to consider them now to help 
> prioritize/rethink/reject.
> 
> In summary we currently have the "stop" action, stopping is immediate 
> (now) and operationalized via the following mechanisms:
> ??????? Ctrl-Z/D
> ??????? System.Exit()
> ??????? Run to completion (normal termination)
> ??????? Unhandled exception :)

Note that in actuality none of those mechanisms are immediate, there are 
lots of things continuing to happen whilst we are in the process of 
"stopping", some of which themselves must run to completion (shutdown 
hooks) whilst others are truly abruptly terminated once the process is 
blown away.

I think Leyden is just looking for a way to signal the end of training 
data collection, not necessarily the end of the program it is being 
collected from.

Cheers,
David
-----

> And this new ask in JBS [1] is to
> ??????? Add a mechanism using 'jcmd' and/or a new Leyden API to action 
> the existing "stop" (now) functionality
> ??????? Add a variant of the "stop" action where training stops when 
> execution enters a java method (optionally after N invocations); specify 
> method to stop on via Command Line (-XX), JCmd and/or Leyden API
> 
> We?d like to propose two additional variants to aid with stopping 
> training runs:
> ??????? Stop training after some time has elapsed
> ??????? Stop training when some threshold is met
> 
> The second point comes from considering the definition of 'startup 
> complete' and 'warmup complete'. ?Considering the developer is already 
> engaged in AOT training, we should allow the developer to aid the 
> training by:
> ??????? Indicating when the application has completed startup (ready to 
> work)
> ??????? Indicate when the application has completed warmup, either by:
> ????????????? Calling an API to indicate warmup is done
> ????????????? Calling an API when a chunk of work has completed, passing 
> in the 'duration'; this 'duration' is compared to some specified 
> 'threshold' to generate the 'warmup is complete' event
> 
> Adding a threshold means that training runs can be of optimal length and 
> can handle changes in the environment and/or code. ?Coupled with maybe 
> an "abort training" action we now have a training run that targets a 
> threshold and aborts if not reached in time N.
> 
> Currently we have the command line, jcmd and a new Leyden API to support 
> training runs. ?Lastly we'd like to propose a fourth method that being 
> an MxBean (uses the new Leyden API); this would allow the developer to 
> provide the startup and warmup indicators internally or externally 
> (their choice), and would allow for runtime analysis using bespoke 
> production systems or JMC, and offline analysis via JFR.
> 
> Cheers
> Mat
> 
> [1] https://bugs.openjdk.org/browse/JDK-8335358 
> <https://bugs.openjdk.org/browse/JDK-8335358>
> 
> From: leyden-dev <leyden-dev-retn at openjdk.org> on behalf of John Rose 
> <john.r.rose at oracle.com>
> Date: Friday, August 16, 2024 at 4:51 PM
> To: ioi.lam at oracle.com <ioi.lam at oracle.com>
> Cc: leyden-dev at openjdk.org <leyden-dev at openjdk.org>
> Subject: Re: EA feedback
> 
> Here?s the way I would prefer to think about a ?dump command?.
> 
> The native way that the JVM represents sequential operations is
> the method. Talking about methods is therefore a basic way to
> specify a condition for injecting a JVM operation like training
> dumps. I would like to figure out a good way to tie the training
> dump to the invocation of a method, either a single well-known
> method, or to a method specified (on the command line) by the
> user.
> 
> In fact, it feels like a breakpoint-like operation would be a
> natural way to view the training dump. You don?t need JVMTI
> to get it done; you just need a hack in the VM which parallels
> the existing breakpoint mechanism, but special-cases it to
> drive a training dump.
> 
> Given such a foundation, jsig could then inject a call to a
> method which is appropriately tied to the dump command.
> 
> Sketch of implementation:
> 
> When a method is first linked, a list is checked to see if
> it has a dump event tied to it, and a bit is set on the method.
> The method?s interpreter entry point might be modified, or
> perhaps the interpreter just always checks the bit. On entry
> to the method, before the first bytecode, an upcall tells
> the VM that it?s time to finish the training run.
> 
> The compilers also check this bit, of course.
> 
> There is some method deep in the privates of java.base
> that is always treated this way. That?s what jcmd reaches.
> There is a command line option which lists more methods
> to treat this way, something like the CompileOnly command.
> 
> As a separate option, the upcall to end the training run
> might return (allowing the VM to continue) or just exit.
> 
> As a separate option, allow the user to specify a count N,
> so that the training dump happens only after N ?hits? on
> any marked method(s).
> 
> I think all this is useful and flexible.
> 
> On 13 Aug 2024, at 18:22, ioi.lam at oracle.com wrote:
> 
> 
>     On 8/13/24 12:42 PM, Ashutosh Mehra wrote:
>>
>>         Being able to trigger assembly/verification via jcmd without
>>         exiting,?would make this far easier for?us to support.
>>
>>     There is a proposed enhancement for doing exactly this (and
>>     exploring other ways to trigger end of training run); see
>>     https://bugs.openjdk.org/browse/JDK-8335358
> 
> 
>     I am working on a prototype for dumping with jcmd. It will be
>     similar to the existing "jcmd VM.cds statoc_dump" command, except
>     that it will also support the dumping of the AOT cache and profile data.
> 
> 
>     Thanks
> 
>     - Ioi
> 
> 
>>
>>     Thanks,
>>     - Ashutosh Mehra
>>
>>
>>     On Fri, Aug 9, 2024 at 4:38?PM Danny Thomas <dannyt at netflix.com>
>>     wrote:
>>
>>         I tried?24-leydenpremain+2-8 on a few internal applications,
>>         some quick feedback below (good to see you folks at the JVM LS!).
>>
>>         If a jar has a Class-Path attribute and?one or more of those
>>         libraries are explicitly on the classpath, it causes the
>>         actual and expected classpath to always differ. This is also
>>         the case currently with CDS of course, but this feature is
>>         sure to be deployed far more broadly than CDS is currently, so
>>         likely something you want to look at:
>>
>>         [0.057s][info][class,path] non-existent Class-Path entry
>>         lib/failureaccess-1.0.1.jar
>>         [0.057s][info][class,path] opened:
>>         lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
>>         [0.057s][info][class,path] library =
>>         lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
>>
>>         Startup time when training seems to be on par
>>         with?ArchiveClassesAtExit in JDK 21, but it's?about a 3.5x
>>         startup time penalty for one of our typical Spring Boot
>>         applications. From a back-to-back run on my machine (AMD EPYC
>>         9R14, 32 cores, 123G, Ubuntu 22.04.4 LTS):
>>
>>         Started App in 7.698 seconds (process running for 8.229)
>>         Started App in 26.247 seconds (process running for 29.262) -
>>         w/ CacheDataStore, Training Run
>>         Started App in 4.341 seconds (process running for 4.917)??- w/
>>         CacheDataStore, Production Run
>>
>>         I also got a crash on one attempt, I can't remember what I did
>>         to cause this unfortunately:
>>
>>         Stack: [0x00007f3949ab0000,0x00007f3949bb0000],
>>         ?sp=0x00007f3949bae628, ?free space=1017k
>>         Native frames: (J=compiled Java code, j=interpreted, Vv=VM
>>         code, C=native code)
>>         V ?[libjvm.so+0x42ca30]
>>         ?ArchiveBuilder::get_buffered_addr(unsigned char*) const+0x40
>>         V ?[libjvm.so+0xce4aa5] ?VM_PopulateDumpSharedSpace::doit()+0x395
>>         V ?[libjvm.so+0x100ae69] ?VM_Operation::evaluate()+0x109
>>         V ?[libjvm.so+0x100e348]
>>         ?VMThread::evaluate_operation(VM_Operation*)+0xe8
>>         V ?[libjvm.so+0x10142fb]
>>         ?VMThread::inner_execute(VM_Operation*)+0x35b
>>         V ?[libjvm.so+0x101460f] ?VMThread::run()+0x16f
>>         V ?[libjvm.so+0xf6e5cf] ?Thread::call_run()+0x9f
>>         V ?[libjvm.so+0xd74e13] ?thread_native_entry(Thread*)+0x183
>>         C ?[libc.so.6+0x98b07]
>>
>>         siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR),
>>         si_addr: 0x0000000000000030
>>
>>         Thinking ahead to operationalizing AOT, while a
>>         single-shot/on-exit workflow is great for iterating locally,
>>         requiring the VM to exit makes this more difficult to
>>         operationalize at scale:
>>
>>          1. We'll perform training and assembly on test, production
>>             canary and production instances on behalf of application
>>             owners and handle distribution of the archives. Depending
>>             on when we're able to perform a training run, it'll have
>>             different benefits. i.e.:
>>              1. Test environment will at least improve startup
>>                 performance, with a mixed benefit for warm up
>>                 depending on the kind of traffic they take in test
>>              2. If an application uses canary deployments we'll have a
>>                 full production profile prior to the full production
>>                 deployment, and all instances will come up hot
>>              3. If we reach production with only a test environment
>>                 profile, we'll perform a training run in production,
>>                 so instances that scale up following that run will
>>                 come up hot (completely cold instances for an initial
>>                 deployment is less of a concern, because we deploy
>>                 immutably and get a natural warm-up period while we
>>                 have 200% capacity online for a cluster)
>>          2. It's currently not a problem if a VM doesn't exit
>>             completely due to a dangling non-daemon thread or hung
>>             shutdown hook
>>
>>         Being able to trigger assembly/verification via jcmd without
>>         exiting,?would make this far easier for?us to support. If the
>>         overhead of the instrumentation for CDS can?be avoided, being
>>         able to take a snapshot at any time on any VM would be better
>>         still, but that wouldn't be an impediment for us:?we'll know
>>         that the instance will be used for training at boot time.
>>
>>         We build nightlies of all the currently active OpenJDK
>>         projects, so if you land anything on premain between EA builds
>>         that you'd like us to try, let us know!
>>
>>         Cheers,
>>         Danny
>>

From Matthew.Carter at microsoft.com  Fri Aug 23 00:37:23 2024
From: Matthew.Carter at microsoft.com (Mat Carter)
Date: Fri, 23 Aug 2024 00:37:23 +0000
Subject: EA feedback
In-Reply-To: <8075078b-eeb7-400e-b169-27b8370f8bf4@oracle.com>
References: <CAABjz10oAmoLkEfLSLo0MN7+BzCFQJ5VYSkmhWH6GB6SVrF57Q@mail.gmail.com>
 <CAKt0pySHtZHSk0FyarM7kkdygTBppHBcYfpXPOfiJuS+7qjQyg@mail.gmail.com>
 <bcf26ac8-663f-4b11-abb3-1ca942d506e2@oracle.com>
 <A0C193BF-B8DB-4BC6-95D5-BBA21DC92F27@oracle.com>
 <BL4PR21MB41283FFEC5120462CF5129368A8F2@BL4PR21MB4128.namprd21.prod.outlook.com>
 <8075078b-eeb7-400e-b169-27b8370f8bf4@oracle.com>
Message-ID: <BL4PR21MB41283FD2F97D82970D23373D8A882@BL4PR21MB4128.namprd21.prod.outlook.com>

Thanks David

I should have been clearer in my response; ?stopping? pertains to the recording of the training data, not necessarily the application itself.  And ?immediate? could be better phrased as ?asap?, both are used in contrast to the other option: ?stop recording training data when some event happens in the future"

From: leyden-dev <leyden-dev-retn at openjdk.org> on behalf of David Holmes <david.holmes at oracle.com>
Date: Thursday, August 22, 2024 at 5:18 PM
To: leyden-dev at openjdk.org <leyden-dev at openjdk.org>
Subject: Re: EA feedback

I'm normally just a lurker here but wanted to clarify one thing ...

On 23/08/2024 2:03 am, Mat Carter wrote:
> Having considered the JBS issue [1], we'd like to propose/discuss some
> additional options, the thought being that while implementation can be
> staggered it might be helpful to consider them now to help
> prioritize/rethink/reject.
>
> In summary we currently have the "stop" action, stopping is immediate
> (now) and operationalized via the following mechanisms:
> ??????? Ctrl-Z/D
> ??????? System.Exit()
> ??????? Run to completion (normal termination)
> ??????? Unhandled exception :)

Note that in actuality none of those mechanisms are immediate, there are
lots of things continuing to happen whilst we are in the process of
"stopping", some of which themselves must run to completion (shutdown
hooks) whilst others are truly abruptly terminated once the process is
blown away.

I think Leyden is just looking for a way to signal the end of training
data collection, not necessarily the end of the program it is being
collected from.

Cheers,
David
-----

> And this new ask in JBS [1] is to
> ??????? Add a mechanism using 'jcmd' and/or a new Leyden API to action
> the existing "stop" (now) functionality
> ??????? Add a variant of the "stop" action where training stops when
> execution enters a java method (optionally after N invocations); specify
> method to stop on via Command Line (-XX), JCmd and/or Leyden API
>
> We?d like to propose two additional variants to aid with stopping
> training runs:
> ??????? Stop training after some time has elapsed
> ??????? Stop training when some threshold is met
>
> The second point comes from considering the definition of 'startup
> complete' and 'warmup complete'.  Considering the developer is already
> engaged in AOT training, we should allow the developer to aid the
> training by:
> ??????? Indicating when the application has completed startup (ready to
> work)
> ??????? Indicate when the application has completed warmup, either by:
> ????????????? Calling an API to indicate warmup is done
> ????????????? Calling an API when a chunk of work has completed, passing
> in the 'duration'; this 'duration' is compared to some specified
> 'threshold' to generate the 'warmup is complete' event
>
> Adding a threshold means that training runs can be of optimal length and
> can handle changes in the environment and/or code.  Coupled with maybe
> an "abort training" action we now have a training run that targets a
> threshold and aborts if not reached in time N.
>
> Currently we have the command line, jcmd and a new Leyden API to support
> training runs.  Lastly we'd like to propose a fourth method that being
> an MxBean (uses the new Leyden API); this would allow the developer to
> provide the startup and warmup indicators internally or externally
> (their choice), and would allow for runtime analysis using bespoke
> production systems or JMC, and offline analysis via JFR.
>
> Cheers
> Mat
>
> [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.org%2Fbrowse%2FJDK-8335358&data=05%7C02%7Cmatthew.carter%40microsoft.com%7C4ff12f99e9bf4436bff508dcc3091127%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638599690928723295%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=H6qKUl4pFMhTH04QWxrh5Q9JHvUnJXWf%2F3vetY1H%2B%2FA%3D&reserved=0<https://bugs.openjdk.org/browse/JDK-8335358>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.org%2Fbrowse%2FJDK-8335358&data=05%7C02%7Cmatthew.carter%40microsoft.com%7C4ff12f99e9bf4436bff508dcc3091127%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638599690928733661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=6hpy60KVGSP3GT8TGtsJxaNNr5GBTihuMhcjiEzo7Qk%3D&reserved=0<https://bugs.openjdk.org/browse/JDK-8335358>>
>
> From: leyden-dev <leyden-dev-retn at openjdk.org> on behalf of John Rose
> <john.r.rose at oracle.com>
> Date: Friday, August 16, 2024 at 4:51 PM
> To: ioi.lam at oracle.com <ioi.lam at oracle.com>
> Cc: leyden-dev at openjdk.org <leyden-dev at openjdk.org>
> Subject: Re: EA feedback
>
> Here?s the way I would prefer to think about a ?dump command?.
>
> The native way that the JVM represents sequential operations is
> the method. Talking about methods is therefore a basic way to
> specify a condition for injecting a JVM operation like training
> dumps. I would like to figure out a good way to tie the training
> dump to the invocation of a method, either a single well-known
> method, or to a method specified (on the command line) by the
> user.
>
> In fact, it feels like a breakpoint-like operation would be a
> natural way to view the training dump. You don?t need JVMTI
> to get it done; you just need a hack in the VM which parallels
> the existing breakpoint mechanism, but special-cases it to
> drive a training dump.
>
> Given such a foundation, jsig could then inject a call to a
> method which is appropriately tied to the dump command.
>
> Sketch of implementation:
>
> When a method is first linked, a list is checked to see if
> it has a dump event tied to it, and a bit is set on the method.
> The method?s interpreter entry point might be modified, or
> perhaps the interpreter just always checks the bit. On entry
> to the method, before the first bytecode, an upcall tells
> the VM that it?s time to finish the training run.
>
> The compilers also check this bit, of course.
>
> There is some method deep in the privates of java.base
> that is always treated this way. That?s what jcmd reaches.
> There is a command line option which lists more methods
> to treat this way, something like the CompileOnly command.
>
> As a separate option, the upcall to end the training run
> might return (allowing the VM to continue) or just exit.
>
> As a separate option, allow the user to specify a count N,
> so that the training dump happens only after N ?hits? on
> any marked method(s).
>
> I think all this is useful and flexible.
>
> On 13 Aug 2024, at 18:22, ioi.lam at oracle.com wrote:
>
>
>     On 8/13/24 12:42 PM, Ashutosh Mehra wrote:
>>
>>         Being able to trigger assembly/verification via jcmd without
>>         exiting, would make this far easier for us to support.
>>
>>     There is a proposed enhancement for doing exactly this (and
>>     exploring other ways to trigger end of training run); see
>>     https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.org%2Fbrowse%2FJDK-8335358&data=05%7C02%7Cmatthew.carter%40microsoft.com%7C4ff12f99e9bf4436bff508dcc3091127%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638599690928736831%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ANr2CrEAfwqp5jeANKhMquiV77Xt%2Fntd7x4cEWdnasM%3D&reserved=0<https://bugs.openjdk.org/browse/JDK-8335358>
>
>
>     I am working on a prototype for dumping with jcmd. It will be
>     similar to the existing "jcmd VM.cds statoc_dump" command, except
>     that it will also support the dumping of the AOT cache and profile data.
>
>
>     Thanks
>
>     - Ioi
>
>
>>
>>     Thanks,
>>     - Ashutosh Mehra
>>
>>
>>     On Fri, Aug 9, 2024 at 4:38?PM Danny Thomas <dannyt at netflix.com>
>>     wrote:
>>
>>         I tried 24-leydenpremain+2-8 on a few internal applications,
>>         some quick feedback below (good to see you folks at the JVM LS!).
>>
>>         If a jar has a Class-Path attribute and one or more of those
>>         libraries are explicitly on the classpath, it causes the
>>         actual and expected classpath to always differ. This is also
>>         the case currently with CDS of course, but this feature is
>>         sure to be deployed far more broadly than CDS is currently, so
>>         likely something you want to look at:
>>
>>         [0.057s][info][class,path] non-existent Class-Path entry
>>         lib/failureaccess-1.0.1.jar
>>         [0.057s][info][class,path] opened:
>>         lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
>>         [0.057s][info][class,path] library =
>>         lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
>>
>>         Startup time when training seems to be on par
>>         with ArchiveClassesAtExit in JDK 21, but it's about a 3.5x
>>         startup time penalty for one of our typical Spring Boot
>>         applications. From a back-to-back run on my machine (AMD EPYC
>>         9R14, 32 cores, 123G, Ubuntu 22.04.4 LTS):
>>
>>         Started App in 7.698 seconds (process running for 8.229)
>>         Started App in 26.247 seconds (process running for 29.262) -
>>         w/ CacheDataStore, Training Run
>>         Started App in 4.341 seconds (process running for 4.917)  - w/
>>         CacheDataStore, Production Run
>>
>>         I also got a crash on one attempt, I can't remember what I did
>>         to cause this unfortunately:
>>
>>         Stack: [0x00007f3949ab0000,0x00007f3949bb0000],
>>          sp=0x00007f3949bae628,  free space=1017k
>>         Native frames: (J=compiled Java code, j=interpreted, Vv=VM
>>         code, C=native code)
>>         V  [libjvm.so+0x42ca30]
>>          ArchiveBuilder::get_buffered_addr(unsigned char*) const+0x40
>>         V  [libjvm.so+0xce4aa5]  VM_PopulateDumpSharedSpace::doit()+0x395
>>         V  [libjvm.so+0x100ae69]  VM_Operation::evaluate()+0x109
>>         V  [libjvm.so+0x100e348]
>>          VMThread::evaluate_operation(VM_Operation*)+0xe8
>>         V  [libjvm.so+0x10142fb]
>>          VMThread::inner_execute(VM_Operation*)+0x35b
>>         V  [libjvm.so+0x101460f]  VMThread::run()+0x16f
>>         V  [libjvm.so+0xf6e5cf]  Thread::call_run()+0x9f
>>         V  [libjvm.so+0xd74e13]  thread_native_entry(Thread*)+0x183
>>         C  [libc.so.6+0x98b07]
>>
>>         siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR),
>>         si_addr: 0x0000000000000030
>>
>>         Thinking ahead to operationalizing AOT, while a
>>         single-shot/on-exit workflow is great for iterating locally,
>>         requiring the VM to exit makes this more difficult to
>>         operationalize at scale:
>>
>>          1. We'll perform training and assembly on test, production
>>             canary and production instances on behalf of application
>>             owners and handle distribution of the archives. Depending
>>             on when we're able to perform a training run, it'll have
>>             different benefits. i.e.:
>>              1. Test environment will at least improve startup
>>                 performance, with a mixed benefit for warm up
>>                 depending on the kind of traffic they take in test
>>              2. If an application uses canary deployments we'll have a
>>                 full production profile prior to the full production
>>                 deployment, and all instances will come up hot
>>              3. If we reach production with only a test environment
>>                 profile, we'll perform a training run in production,
>>                 so instances that scale up following that run will
>>                 come up hot (completely cold instances for an initial
>>                 deployment is less of a concern, because we deploy
>>                 immutably and get a natural warm-up period while we
>>                 have 200% capacity online for a cluster)
>>          2. It's currently not a problem if a VM doesn't exit
>>             completely due to a dangling non-daemon thread or hung
>>             shutdown hook
>>
>>         Being able to trigger assembly/verification via jcmd without
>>         exiting, would make this far easier for us to support. If the
>>         overhead of the instrumentation for CDS can be avoided, being
>>         able to take a snapshot at any time on any VM would be better
>>         still, but that wouldn't be an impediment for us: we'll know
>>         that the instance will be used for training at boot time.
>>
>>         We build nightlies of all the currently active OpenJDK
>>         projects, so if you land anything on premain between EA builds
>>         that you'd like us to try, let us know!
>>
>>         Cheers,
>>         Danny
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240823/b55a1b51/attachment.htm>

From duke at openjdk.org  Fri Aug 23 05:03:42 2024
From: duke at openjdk.org (duke)
Date: Fri, 23 Aug 2024 05:03:42 GMT
Subject: git: openjdk/leyden: premain: 93 new changesets
Message-ID: <d8b48c5c-e036-4327-ab3c-1a665814e67e@openjdk.org>

Changeset: f132b347
Branch: premain
Author:    SendaoYan <syan at openjdk.org>
Committer: Rajan Halade <rhalade at openjdk.org>
Date:      2024-08-13 22:59:13 +0000
URL:       https://git.openjdk.org/leyden/commit/f132b347e13a57d9654f0ab11db0636999576036

8336854: CAInterop.java#actalisauthenticationrootca conflicted with /manual and /timeout

Reviewed-by: rhalade

! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java

Changeset: 720b4464
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-08-14 05:42:14 +0000
URL:       https://git.openjdk.org/leyden/commit/720b44648bcff997278af92746f942b2425298a5

8335181: Incorrect handling of HTTP/2 GOAWAY frames in HttpClient

Reviewed-by: dfuchs

! src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java
! src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java
! src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java
! src/java.net.http/share/classes/jdk/internal/net/http/Stream.java
! src/java.net.http/share/classes/jdk/internal/net/http/WindowController.java
! src/java.net.http/share/classes/jdk/internal/net/http/frame/GoAwayFrame.java
+ test/jdk/java/net/httpclient/http2/H2GoAwayTest.java
! test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/HttpServerAdapters.java
! test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestExchange.java
! test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestExchangeImpl.java
! test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestServer.java
! test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestServerConnection.java

Changeset: 3dd07b91
Branch: premain
Author:    Qizheng Xing <qxing at openjdk.org>
Committer: Eric Liu <eliu at openjdk.org>
Date:      2024-08-14 06:28:34 +0000
URL:       https://git.openjdk.org/leyden/commit/3dd07b91bbf644aa867452806e9388089fa97548

8336163: Remove declarations of some debug-only methods in release build

Reviewed-by: dholmes, eliu, kvn

! src/hotspot/share/cds/heapShared.hpp
! src/hotspot/share/compiler/compilationPolicy.hpp
! src/hotspot/share/opto/node.hpp
! src/hotspot/share/runtime/frame.hpp
! src/hotspot/share/runtime/registerMap.hpp

Changeset: 66bee253
Branch: premain
Author:    Ivan Walulya <iwalulya at openjdk.org>
Date:      2024-08-14 09:13:21 +0000
URL:       https://git.openjdk.org/leyden/commit/66bee2532f849cfb7ab63857ecd7d773c2566722

8338315: G1: G1CardTableEntryClosure:do_card_ptr remove unused parameter worker_id

Reviewed-by: tschatzl

! src/hotspot/share/gc/g1/g1CardTableEntryClosure.hpp
! src/hotspot/share/gc/g1/g1RemSet.cpp
! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp

Changeset: 9fe1777f
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-08-14 09:16:02 +0000
URL:       https://git.openjdk.org/leyden/commit/9fe1777fafca30cf60acb5402c7c70800137136e

8338280: Parallel: Inline ParallelCompactData::verify_clear

Reviewed-by: tschatzl

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

Changeset: 38bd8a36
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-08-14 09:52:23 +0000
URL:       https://git.openjdk.org/leyden/commit/38bd8a36704a962f0ad1052fd2ec150a61663256

8338236: Compile error in cgroup code on Linux when using clang

Reviewed-by: mdoerr, sgehwolf

! src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp
! src/hotspot/os/linux/cgroupV2Subsystem_linux.hpp

Changeset: fbe4f056
Branch: premain
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-08-14 12:20:17 +0000
URL:       https://git.openjdk.org/leyden/commit/fbe4f05636c8f692bd40bbe11fb5bb8b77b77042

8337976: Insufficient error recovery in parser for switch inside class body

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/VirtualParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
= test/langtools/tools/javac/diags/examples/StatementNotExpected.java
! test/langtools/tools/javac/parser/JavacParserTest.java
! test/langtools/tools/javac/records/RecordCompilationTests.java
+ test/langtools/tools/javac/recovery/T8337976.java
+ test/langtools/tools/javac/recovery/T8337976.out

Changeset: a5d948fb
Branch: premain
Author:    John Engebretson <jengebr at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-14 14:11:53 +0000
URL:       https://git.openjdk.org/leyden/commit/a5d948fb9841f654cccc9567c60e8d28e7d719ae

8332842: Optimize empty CopyOnWriteArrayList allocations

Reviewed-by: shade, alanb

! src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
+ test/micro/org/openjdk/bench/java/util/concurrent/CopyOnWriteArrayListBenchmark.java

Changeset: d8e4d3f2
Branch: premain
Author:    Zdenek Zambersky <zzambers at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-14 15:20:07 +0000
URL:       https://git.openjdk.org/leyden/commit/d8e4d3f2d6c187f2487acd390a4e5fa2a99010ea

8338402: GHA: some of bundles may not get removed

Reviewed-by: ihse, shade

! .github/workflows/main.yml

Changeset: 0e3903f2
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-08-14 16:49:11 +0000
URL:       https://git.openjdk.org/leyden/commit/0e3903f2eb854715acee92cfc5ee2d4a2e800f61

8338393: Parallel: Remove unused ParallelCompactData::clear_range

Reviewed-by: tschatzl

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

Changeset: 6a390147
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-08-14 16:56:28 +0000
URL:       https://git.openjdk.org/leyden/commit/6a390147959e0fb88de6ee13204cff72cd910f09

8338110: Exclude Fingerprinter::do_type from ubsan checks

Reviewed-by: jwaters, rrich

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

Changeset: c0384b6f
Branch: premain
Author:    Phil Race <prr at openjdk.org>
Date:      2024-08-14 17:58:24 +0000
URL:       https://git.openjdk.org/leyden/commit/c0384b6f3584501fb3bd93854734eeacf6620a7e

8337237: Use FFM instead of Unsafe for Java 2D RenderBuffer class

Reviewed-by: jvernee, jdv

! src/java.desktop/share/classes/sun/java2d/pipe/RenderBuffer.java

Changeset: 723ac576
Branch: premain
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-08-14 18:41:24 +0000
URL:       https://git.openjdk.org/leyden/commit/723ac5763aed0d67516c6746f39a066efc412b48

8332488: Add JVMTI DataDumpRequest to the debug agent

Reviewed-by: sspitsyn, lmesnik

! src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c
! src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c
! src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.h
! src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c
! src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.h
! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c
! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.h
! src/jdk.jdwp.agent/share/native/libjdwp/util.c
! src/jdk.jdwp.agent/share/native/libjdwp/util.h
+ test/jdk/com/sun/jdi/DataDumpTest.java

Changeset: aff7936f
Branch: premain
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-08-14 18:42:59 +0000
URL:       https://git.openjdk.org/leyden/commit/aff7936ff088249d1fc787a9f9ef687f987f556c

8338333: Add jls links to javax.lang.model.element.Modifier

Reviewed-by: liach, iris, prappo, vromero, jlahoda

! src/java.compiler/share/classes/javax/lang/model/element/Modifier.java

Changeset: e3a5e265
Branch: premain
Author:    SendaoYan <syan at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-14 18:55:58 +0000
URL:       https://git.openjdk.org/leyden/commit/e3a5e265a7747b02b8f828fbedea0dda7246fc51

8338344: Test TestPrivilegedMode.java intermittent fails java.lang.NoClassDefFoundError: jdk/test/lib/Platform

Reviewed-by: chagedorn, shade

! test/hotspot/jtreg/compiler/lib/ir_framework/driver/TestVMProcess.java

Changeset: 4669e7b7
Branch: premain
Author:    Evgeny Nikitin <enikitin at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
Date:      2024-08-15 05:36:11 +0000
URL:       https://git.openjdk.org/leyden/commit/4669e7b7b02636a8bd7381a9d401aaaf0c1d7294

8337102: JITTester: Fix breaks in static initialization blocks

Reviewed-by: kvn, iveresov

! test/hotspot/jtreg/testlibrary/jittester/conf/default.properties
! test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/factories/StaticConstructorDefinitionFactory.java

Changeset: 4c344335
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-08-15 07:39:31 +0000
URL:       https://git.openjdk.org/leyden/commit/4c344335fe0abc04308f4bfc62c6b3afc110240c

8338304: clang on Linux - check for lld presence after JDK-8333189

Reviewed-by: erikj, ihse

! make/autoconf/flags-ldflags.m4

Changeset: f536f5ab
Branch: premain
Author:    Ivan Walulya <iwalulya at openjdk.org>
Date:      2024-08-15 08:26:22 +0000
URL:       https://git.openjdk.org/leyden/commit/f536f5ab68235d27e9708674f707bcbff7840730

8336086: G1: Use one G1CardSet instance for all young regions

Reviewed-by: tschatzl, ayang

! src/hotspot/share/gc/g1/g1CardSet.cpp
! src/hotspot/share/gc/g1/g1CardSet.hpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1CollectionSet.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp
! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp
! src/hotspot/share/gc/g1/g1FullCollector.cpp
! src/hotspot/share/gc/g1/g1HeapRegion.cpp
! src/hotspot/share/gc/g1/g1HeapRegion.hpp
! src/hotspot/share/gc/g1/g1HeapRegion.inline.hpp
! src/hotspot/share/gc/g1/g1HeapRegionRemSet.cpp
! src/hotspot/share/gc/g1/g1HeapRegionRemSet.hpp
! src/hotspot/share/gc/g1/g1HeapRegionRemSet.inline.hpp
! src/hotspot/share/gc/g1/g1Policy.cpp
! src/hotspot/share/gc/g1/g1Policy.hpp
! src/hotspot/share/gc/g1/g1RemSet.cpp
! src/hotspot/share/gc/g1/g1RemSetSummary.cpp
! src/hotspot/share/gc/g1/g1YoungCollector.cpp
! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp

Changeset: da7311bb
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-15 08:50:29 +0000
URL:       https://git.openjdk.org/leyden/commit/da7311bbe37c2b9632b117d52a77c659047820b7

8338286: GHA: Demote x86_32 to hotspot build only

Reviewed-by: ihse

! .github/workflows/main.yml

Changeset: 74fdd686
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-15 11:24:22 +0000
URL:       https://git.openjdk.org/leyden/commit/74fdd6868d3f71d44ef9f71a0ca9506c04d39148

8333791: Fix memory barriers for @Stable fields

Reviewed-by: liach, vlivanov

! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/c1/c1_IR.cpp
! src/hotspot/share/c1/c1_IR.hpp
! src/hotspot/share/opto/parse.hpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/parse3.cpp
+ test/hotspot/jtreg/compiler/c2/irTests/stable/StablePrimArrayTest.java
+ test/hotspot/jtreg/compiler/c2/irTests/stable/StablePrimFinalTest.java
+ test/hotspot/jtreg/compiler/c2/irTests/stable/StablePrimPlainTest.java
+ test/hotspot/jtreg/compiler/c2/irTests/stable/StablePrimVolatileTest.java
+ test/hotspot/jtreg/compiler/c2/irTests/stable/StableRefArrayTest.java
+ test/hotspot/jtreg/compiler/c2/irTests/stable/StableRefFinalTest.java
+ test/hotspot/jtreg/compiler/c2/irTests/stable/StableRefPlainTest.java
+ test/hotspot/jtreg/compiler/c2/irTests/stable/StableRefVolatileTest.java

Changeset: 56dec215
Branch: premain
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
Date:      2024-08-15 13:28:25 +0000
URL:       https://git.openjdk.org/leyden/commit/56dec215b0d056fc23137372ecb3376af2a7b891

8338014: Improve usage of @jvms tags in class file API

Reviewed-by: darcy, liach, asotona

! src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
! src/java.base/share/classes/java/lang/classfile/Attribute.java
! src/java.base/share/classes/java/lang/classfile/ClassSignature.java
! src/java.base/share/classes/java/lang/classfile/MethodSignature.java
! src/java.base/share/classes/java/lang/classfile/Opcode.java
! src/java.base/share/classes/java/lang/classfile/Signature.java
! src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
! src/java.base/share/classes/java/lang/classfile/attribute/AnnotationDefaultAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/BootstrapMethodsAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/CodeAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/ConstantValueAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/DeprecatedAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/EnclosingMethodAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/ExceptionsAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/InnerClassesAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/LineNumberTableAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTableAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTypeTableAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/MethodParametersAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/ModuleAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/ModuleMainClassAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/ModulePackagesAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/NestHostAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/NestMembersAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/PermittedSubclassesAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/RecordAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleAnnotationsAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleParameterAnnotationsAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleTypeAnnotationsAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleAnnotationsAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleParameterAnnotationsAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleTypeAnnotationsAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/SignatureAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/SourceFileAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/StackMapFrameInfo.java
! src/java.base/share/classes/java/lang/classfile/attribute/StackMapTableAttribute.java
! src/java.base/share/classes/java/lang/classfile/attribute/SyntheticAttribute.java
! src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java
! src/java.base/share/classes/java/lang/classfile/constantpool/MethodHandleEntry.java
! src/java.base/share/classes/java/lang/classfile/instruction/InvokeInstruction.java

Changeset: 38591315
Branch: premain
Author:    Fei Gao <fgao at openjdk.org>
Date:      2024-08-15 15:16:14 +0000
URL:       https://git.openjdk.org/leyden/commit/38591315058e6d3b764ca325facc5bf46bf7b16b

8338442: AArch64: Clean up IndOffXX type and let legitimize_address() fix out-of-range operands

Reviewed-by: aph, dlong

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/aarch64_vector.ad
! src/hotspot/cpu/aarch64/aarch64_vector_ad.m4
! src/hotspot/cpu/aarch64/ad_encode.m4
! src/hotspot/cpu/aarch64/gc/x/x_aarch64.ad
! src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad
! test/hotspot/jtreg/compiler/c2/TestUnalignedAccess.java

Changeset: 6169613d
Branch: premain
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-08-15 15:34:08 +0000
URL:       https://git.openjdk.org/leyden/commit/6169613d9f3f0bf019d04a37a1d8f28f1463c17c

8336655: java/net/httpclient/DigestEchoClient.java IOException: HTTP/1.1 header parser received no bytes

Reviewed-by: jpai

! src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
! src/java.net.http/share/classes/jdk/internal/net/http/SocketTube.java
! test/jdk/java/net/httpclient/DigestEchoClient.java

Changeset: 7d1bbff0
Branch: premain
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Harshitha Onkar <honkar at openjdk.org>
Date:      2024-08-15 16:36:15 +0000
URL:       https://git.openjdk.org/leyden/commit/7d1bbff076c063d066951eedb21de7e694e588b3

8328553: Get rid of JApplet in test/jdk/sanity/client/lib/SwingSet2/src/DemoModule.java

Reviewed-by: honkar, prr

! test/jdk/sanity/client/lib/SwingSet2/src/DemoModule.java

Changeset: ef54af39
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-15 16:45:43 +0000
URL:       https://git.openjdk.org/leyden/commit/ef54af39883e76c80a3e012ed91b90973da51bb4

8338444: Shenandoah: Remove ShenandoahHumongousThreshold tunable

Reviewed-by: rkennke, wkemper, ysr

! src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp
! src/hotspot/share/gc/shenandoah/shenandoahController.cpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/shenandoahInitLogger.cpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp
- test/hotspot/jtreg/gc/shenandoah/TestHumongousThreshold.java
- test/hotspot/jtreg/gc/shenandoah/options/TestHumongousThresholdArgs.java

Changeset: e51e40c2
Branch: premain
Author:    Satyen Subramaniam <satyenme at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-15 16:47:08 +0000
URL:       https://git.openjdk.org/leyden/commit/e51e40c2b9f51d012c01407e0b8dadaab464753e

8336914: Shenandoah: Missing verification steps after JDK-8255765

Reviewed-by: shade

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

Changeset: f308b2d5
Branch: premain
Author:    Satyen Subramaniam <satyenme at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-15 16:47:45 +0000
URL:       https://git.openjdk.org/leyden/commit/f308b2d59672b39ddca502baff50ab20ab781047

8336915: Shenandoah: Remove unused ShenandoahVerifier::verify_after_evacuation

Reviewed-by: shade

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

Changeset: 96550827
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-08-15 17:43:09 +0000
URL:       https://git.openjdk.org/leyden/commit/965508270ecd092019f7bea3a1605c5d9f19d81e

8338330: Fix -Wzero-as-null-pointer-constant warnings from THROW_XXX_0

Reviewed-by: dlong, dholmes, shade

! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/reflection.cpp
! src/hotspot/share/utilities/exceptions.hpp

Changeset: ace49651
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-08-15 17:50:34 +0000
URL:       https://git.openjdk.org/leyden/commit/ace496515f4f91e802a51cec43d387eed61bd935

8338406: BytecodeHelpers using wrong bootstrap method descriptor for condy

Reviewed-by: asotona

! src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java
+ test/jdk/jdk/classfile/ConstantDescSymbolsTest.java
- test/jdk/jdk/classfile/PrimitiveClassConstantTest.java

Changeset: 52d9d69d
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-08-15 17:50:44 +0000
URL:       https://git.openjdk.org/leyden/commit/52d9d69db5c1853445a95794c5bf21243aefa852

8338331: Fix -Wzero-as-null-pointer-constant warnings from CHECK_0 in jni.cpp

Reviewed-by: dholmes, shade

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

Changeset: 1cd48843
Branch: premain
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-08-15 18:20:20 +0000
URL:       https://git.openjdk.org/leyden/commit/1cd488436880b00c55fa91f44c115999cf686afd

8338447: Remove InstanceKlass::_is_marked_dependent

Reviewed-by: shade

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

Changeset: d86e99c3
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-15 20:52:07 +0000
URL:       https://git.openjdk.org/leyden/commit/d86e99c3ca94ee8705e44fe2830edd3ceb0a7f64

8293650: Shenandoah: Support archived heap objects

Reviewed-by: rkennke, wkemper, iklam

! src/hotspot/share/cds/archiveHeapWriter.hpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
+ test/hotspot/jtreg/runtime/cds/appcds/TestShenandoahWithCDS.java

Changeset: 74066bcc
Branch: premain
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Claes Redestad <redestad at openjdk.org>
Date:      2024-08-15 22:57:33 +0000
URL:       https://git.openjdk.org/leyden/commit/74066bcca82749722e6fee57469520d418bf3430

8338409: Use record to simplify code

Reviewed-by: redestad, liach

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

Changeset: bd4160ce
Branch: premain
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2024-08-16 06:20:17 +0000
URL:       https://git.openjdk.org/leyden/commit/bd4160cea8b6b0fcf0507199ed76a12f5d0aaba9

8315884: New Object to ObjectMonitor mapping

Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
Co-authored-by: Coleen Phillimore <coleenp at openjdk.org>
Reviewed-by: rkennke, coleenp, dcubed

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/arm/interp_masm_arm.cpp
! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/interp_masm_riscv.cpp
! src/hotspot/cpu/s390/interp_masm_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/interp_masm_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/sharedRuntime_x86.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp
! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/logging/logTag.hpp
! src/hotspot/share/oops/markWord.cpp
! src/hotspot/share/oops/markWord.hpp
! src/hotspot/share/opto/c2_CodeStubs.hpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/prims/jvmtiEnvBase.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/basicLock.cpp
! src/hotspot/share/runtime/basicLock.hpp
+ src/hotspot/share/runtime/basicLock.inline.hpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/javaThread.inline.hpp
+ src/hotspot/share/runtime/lightweightSynchronizer.cpp
+ src/hotspot/share/runtime/lightweightSynchronizer.hpp
! src/hotspot/share/runtime/lockStack.cpp
! src/hotspot/share/runtime/lockStack.hpp
! src/hotspot/share/runtime/lockStack.inline.hpp
! src/hotspot/share/runtime/objectMonitor.cpp
! src/hotspot/share/runtime/objectMonitor.hpp
! src/hotspot/share/runtime/objectMonitor.inline.hpp
! src/hotspot/share/runtime/safepoint.cpp
! src/hotspot/share/runtime/serviceThread.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/synchronizer.hpp
+ src/hotspot/share/runtime/synchronizer.inline.hpp
! src/hotspot/share/runtime/vframe.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Mark.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/BasicLock.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ObjectMonitor.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ObjectSynchronizer.java
! test/hotspot/gtest/runtime/test_objectMonitor.cpp
+ test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java
! test/hotspot/jtreg/runtime/logging/MonitorInflationTest.java
! test/micro/org/openjdk/bench/vm/lang/LockUnlock.java

Changeset: 60c9b5cd
Branch: premain
Author:    Andrey Turbanov <aturbanov at openjdk.org>
Date:      2024-08-16 08:49:18 +0000
URL:       https://git.openjdk.org/leyden/commit/60c9b5cd9f18830f0fb1aea6cb3dc43af3908cc5

8337839: Make a few fields in MergeCollation static

Reviewed-by: jpai, naoto

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

Changeset: ddbc0b6a
Branch: premain
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-08-16 11:24:40 +0000
URL:       https://git.openjdk.org/leyden/commit/ddbc0b6a39148cb30a8fda80fa7290e90e2a77d6

8338495: Revert "8336655: java/net/httpclient/DigestEchoClient.java IOException: HTTP/1.1 header parser received no bytes"

Reviewed-by: jpai

! src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
! src/java.net.http/share/classes/jdk/internal/net/http/SocketTube.java
! test/jdk/java/net/httpclient/DigestEchoClient.java

Changeset: 5022109b
Branch: premain
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Claes Redestad <redestad at openjdk.org>
Date:      2024-08-16 13:18:02 +0000
URL:       https://git.openjdk.org/leyden/commit/5022109b2a33a8cf2608eb829098b27641b731a4

8336856: Efficient hidden class-based string concatenation strategy

Co-authored-by: Claes Redestad <redestad at openjdk.org>
Reviewed-by: redestad, liach

! src/java.base/share/classes/java/lang/StringConcatHelper.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java
+ test/jdk/java/lang/String/concat/HiddenClassUnloading.java
! test/micro/org/openjdk/bench/java/lang/StringConcat.java
! test/micro/org/openjdk/bench/java/lang/StringConcatStartup.java

Changeset: 07352c67
Branch: premain
Author:    Pavel Rappo <prappo at openjdk.org>
Date:      2024-08-16 14:06:10 +0000
URL:       https://git.openjdk.org/leyden/commit/07352c67448f3f35827395c83ac95e3ca0e4c6bc

8338398: Trivially fix grammar and typos

Reviewed-by: aivanov

! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java
! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java
! src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java

Changeset: 961e944f
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-08-16 15:48:54 +0000
URL:       https://git.openjdk.org/leyden/commit/961e944fa731dc84be2764c01e4b326187474605

8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation

Co-authored-by: Alex Buckley <abuckley at openjdk.org>
Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/Annotation.java
! src/java.base/share/classes/java/lang/classfile/AnnotationElement.java
! src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
! src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractAttributeMapper.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassRemapperImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/UnboundAttribute.java
! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/AnnotationWriter.java
! test/jdk/jdk/classfile/ClassPrinterTest.java
! test/jdk/jdk/classfile/TransformTests.java
! test/jdk/jdk/classfile/helpers/ClassRecord.java
! test/jdk/jdk/classfile/helpers/RebuildingTransformation.java
! test/langtools/lib/annotations/annotations/classfile/ClassfileInspector.java
! test/langtools/tools/javac/annotations/typeAnnotations/classfile/AnonymousClassTest.java
! test/langtools/tools/javac/annotations/typeAnnotations/referenceinfos/ReferenceInfoUtil.java
! test/langtools/tools/javac/patterns/Annotations.java
! test/langtools/tools/javac/records/RecordCompilationTests.java

Changeset: 8635642d
Branch: premain
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-08-16 16:39:36 +0000
URL:       https://git.openjdk.org/leyden/commit/8635642dbdfb74d2ae50a51611fd2c5980fe6e74

8338469: com/sun/jdi/DataDumpTest.java failed with Not a debuggee, or not listening for debugger to attach

Reviewed-by: dcubed

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

Changeset: 2f7ba781
Branch: premain
Author:    SendaoYan <syan at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
Date:      2024-08-19 04:44:24 +0000
URL:       https://git.openjdk.org/leyden/commit/2f7ba781bf2e4e6d0fa658c19f86c6c05d60358a

8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment

Reviewed-by: jpai

! test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java

Changeset: 56a007dd
Branch: premain
Author:    Tejesh R <tr at openjdk.org>
Date:      2024-08-19 06:42:51 +0000
URL:       https://git.openjdk.org/leyden/commit/56a007dd32061695d7bb0faf47e1793728e86c88

8338488: Add screen capture for failure case

Reviewed-by: azvegint

! test/jdk/java/awt/Checkbox/CheckboxCheckerScalingTest.java

Changeset: 15b20cb1
Branch: premain
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Tejesh R <tr at openjdk.org>
Date:      2024-08-19 07:17:37 +0000
URL:       https://git.openjdk.org/leyden/commit/15b20cb1fd18b849e49c175737dd3826c8d0ceff

8337886: java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color difference

Reviewed-by: dnguyen, honkar, serb

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

Changeset: f0374a0b
Branch: premain
Author:    Andrew Dinn <adinn at openjdk.org>
Date:      2024-08-19 09:00:19 +0000
URL:       https://git.openjdk.org/leyden/commit/f0374a0bc181d0f2a8c0aa9aa032b07998ffaf60

8337987: Relocate jfr and throw_exception stubs from StubGenerator to SharedRuntime

Reviewed-by: fyang, kvn, yzheng

! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp
! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
! src/hotspot/cpu/arm/methodHandles_arm.cpp
! src/hotspot/cpu/arm/sharedRuntime_arm.cpp
! src/hotspot/cpu/arm/stubGenerator_arm.cpp
! src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/methodHandles_ppc.cpp
! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp
! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/methodHandles_riscv.cpp
! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp
! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp
! src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.cpp
! src/hotspot/cpu/s390/methodHandles_s390.cpp
! src/hotspot/cpu/s390/sharedRuntime_s390.cpp
! src/hotspot/cpu/s390/stubGenerator_s390.cpp
! src/hotspot/cpu/s390/templateInterpreterGenerator_s390.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/methodHandles_x86.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.hpp
! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
! src/hotspot/cpu/zero/sharedRuntime_zero.cpp
! src/hotspot/cpu/zero/stubGenerator_zero.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/runtime/init.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/sharedRuntime.hpp
! src/hotspot/share/runtime/stubRoutines.cpp
! src/hotspot/share/runtime/stubRoutines.hpp

Changeset: 6d430f24
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-19 09:08:54 +0000
URL:       https://git.openjdk.org/leyden/commit/6d430f24df9d599fe1e12c6b65117c02773ae5d8

8338314: JFR: Split JFRCheckpoint VM operation

Reviewed-by: mgronlun, egahlin

! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp
! src/hotspot/share/jfr/recorder/service/jfrRecorderService.hpp
! src/hotspot/share/runtime/vmOperation.hpp

Changeset: e07a5b66
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-08-19 10:42:58 +0000
URL:       https://git.openjdk.org/leyden/commit/e07a5b66267156f55ee1c28579382990e58f15eb

8338512: JFR: Revert changes to TestCodeSweeper

Reviewed-by: mgronlun

! test/jdk/ProblemList.txt
! test/jdk/jdk/jfr/event/compiler/TestCodeSweeper.java

Changeset: 6ff6b099
Branch: premain
Author:    Renjith Kannath Pariyangad <rkannathpari at openjdk.org>
Date:      2024-08-19 12:40:35 +0000
URL:       https://git.openjdk.org/leyden/commit/6ff6b0994380276e0096f7b55a0d659803344679

8290501: Typo in javax.swing.BoundedRangeModel documentation

Reviewed-by: aivanov, prr, honkar

! src/java.desktop/share/classes/javax/swing/BoundedRangeModel.java

Changeset: f0fe3138
Branch: premain
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-08-19 12:57:17 +0000
URL:       https://git.openjdk.org/leyden/commit/f0fe31383aec652ad4e3cc4873cd3ff9b918fef7

8338564: Remove obsolete AbstractNamedEntry::equals method

Reviewed-by: liach

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

Changeset: 2766b09e
Branch: premain
Author:    Alan Bateman <alanb at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
Date:      2024-08-19 12:57:29 +0000
URL:       https://git.openjdk.org/leyden/commit/2766b09e29d7c1c31fdef20f016a181eedb2d429

8338452: (dc) DatagramChannelImpl.blockingReceive with timeout may block indefinitely if all datagrams blocked by SecurityManager

Reviewed-by: dfuchs

! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java

Changeset: 3ca359ad
Branch: premain
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-08-19 13:47:40 +0000
URL:       https://git.openjdk.org/leyden/commit/3ca359ad224b07f283c99eb43bed02eb93ef2dc7

8335771: Improve stability of java/nio/channels/DatagramChannel tests

Reviewed-by: alanb

! test/jdk/java/nio/channels/DatagramChannel/AdaptorMulticasting.java
! test/jdk/java/nio/channels/DatagramChannel/AfterDisconnect.java
! test/jdk/java/nio/channels/DatagramChannel/Connect.java
! test/jdk/java/nio/channels/DatagramChannel/ManySourcesAndTargets.java
! test/jdk/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java
! test/jdk/java/nio/channels/DatagramChannel/NotBound.java
! test/jdk/java/nio/channels/DatagramChannel/Promiscuous.java
! test/jdk/java/nio/channels/DatagramChannel/ReceiveISA.java
! test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java
! test/jdk/java/nio/channels/DatagramChannel/SendReceiveMaxSize.java
! test/jdk/java/nio/channels/DatagramChannel/Sender.java

Changeset: 6460b300
Branch: premain
Author:    Damon Nguyen <dnguyen at openjdk.org>
Date:      2024-08-19 16:43:43 +0000
URL:       https://git.openjdk.org/leyden/commit/6460b300487071bcf98f5ac70d9c0a6fd6b94083

8321140: Add comment to note difference in Metal's JButton margins

Reviewed-by: honkar, aivanov

! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java
! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java

Changeset: c7690c34
Branch: premain
Author:    Hannes Walln?fer <hannesw at openjdk.org>
Date:      2024-08-19 17:47:25 +0000
URL:       https://git.openjdk.org/leyden/commit/c7690c34c2d7bff11501188266b7be7a486c1bd0

8338190: TOC vertical offsets not updated when document size changes

Reviewed-by: jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script.js.template

Changeset: 55851a31
Branch: premain
Author:    Hannes Walln?fer <hannesw at openjdk.org>
Date:      2024-08-19 18:05:37 +0000
URL:       https://git.openjdk.org/leyden/commit/55851a312baaea5af14c04fb1b436313fe0deac7

8281533: Odd "preview" label in link/linkplain

Reviewed-by: jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlLinkFactory.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/LinkTaglet.java
! test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java
! test/langtools/jdk/javadoc/doclet/testPreview/api/preview/Core.java

Changeset: 68d1f5c3
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-08-20 05:43:04 +0000
URL:       https://git.openjdk.org/leyden/commit/68d1f5c33bf3f64f44f8a10c2f9e4007cfd07d2b

8338543: ClassBuilder withMethod builders should cache the method type symbol

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedClassBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectClassBuilder.java

Changeset: 9775d571
Branch: premain
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2024-08-20 06:15:56 +0000
URL:       https://git.openjdk.org/leyden/commit/9775d57168695dc0d758e017fe5069d93d593f3e

8338139: {ClassLoading,Memory}MXBean::isVerbose methods are inconsistent with their setVerbose methods

Co-authored-by: David Holmes <dholmes at openjdk.org>
Reviewed-by: lmesnik, dcubed, dholmes

! src/hotspot/share/services/classLoadingService.cpp
! src/hotspot/share/services/classLoadingService.hpp
! src/hotspot/share/services/memoryService.cpp
! src/hotspot/share/services/memoryService.hpp
+ test/jdk/java/lang/management/ClassLoadingMXBean/TestVerboseClassLoading.java
+ test/jdk/java/lang/management/MemoryMXBean/TestVerboseMemory.java

Changeset: b9d49dce
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-20 08:40:45 +0000
URL:       https://git.openjdk.org/leyden/commit/b9d49dcef22ab81a087d890bbac0329a5244a2ef

8337981: ShenandoahHeap::is_in should check for alive regions

Reviewed-by: rkennke, wkemper

! src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp
! src/hotspot/share/gc/shenandoah/shenandoahAsserts.hpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp

Changeset: 89ca5b6f
Branch: premain
Author:    Amit Kumar <amitkumar at openjdk.org>
Date:      2024-08-20 09:54:20 +0000
URL:       https://git.openjdk.org/leyden/commit/89ca5b6fbd82f00375b4f96b2f3526078088d3f9

8338365: [PPC64, s390] Out-of-bounds array access in secondary_super_cache

Reviewed-by: mdoerr, aph, rrich

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

Changeset: 7933e45c
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-08-20 10:43:16 +0000
URL:       https://git.openjdk.org/leyden/commit/7933e45cda7e3eaeabd3b3fa81492ade8e1cc2dc

8338550: Do libubsan1 installation in test container only if requested

Reviewed-by: sgehwolf

! test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java
! test/lib/jdk/test/lib/containers/docker/DockerfileConfig.java

Changeset: 01d03e07
Branch: premain
Author:    Darragh Clarke <dclarke at openjdk.org>
Date:      2024-08-20 11:10:18 +0000
URL:       https://git.openjdk.org/leyden/commit/01d03e07c7642e148e4e17848d28686858ea37a7

8324209: Check implementation of Expect: 100-continue in the java.net.http.HttpClient

Reviewed-by: dfuchs, jpai

! src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java
! src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java
! src/java.net.http/share/classes/jdk/internal/net/http/Stream.java
! test/jdk/java/net/httpclient/ExpectContinueTest.java

Changeset: 686eb233
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-08-20 12:28:56 +0000
URL:       https://git.openjdk.org/leyden/commit/686eb233d59ab72e872b8dc32cb14bf74519efc5

8336817: Several methods on DatagramSocket and MulticastSocket do not specify behaviour when already closed or connected

Reviewed-by: dfuchs, alanb

! src/java.base/share/classes/java/net/DatagramSocket.java
! src/java.base/share/classes/java/net/MulticastSocket.java

Changeset: bc2700b7
Branch: premain
Author:    George Adams <gdams at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-08-20 14:38:31 +0000
URL:       https://git.openjdk.org/leyden/commit/bc2700b7dc6039e2a17124a0ca32780383c4a43f

8282944: GHA: Add Alpine Linux x86_64 pre-integration check

Reviewed-by: ihse

! .github/actions/config/action.yml
+ .github/workflows/build-alpine-linux.yml
! .github/workflows/main.yml
! make/conf/github-actions.conf

Changeset: b4420030
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-08-20 14:44:37 +0000
URL:       https://git.openjdk.org/leyden/commit/b442003048559fc35cafddb62885d3ba75b70838

8338623: StackCounter adding extraneous slots for receiver invoke instructions

Reviewed-by: asotona

! src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java
! test/jdk/jdk/classfile/StackMapsTest.java

Changeset: 55a97ec8
Branch: premain
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-08-20 15:47:16 +0000
URL:       https://git.openjdk.org/leyden/commit/55a97ec8793242c0cacbafd3a4fead25cdce2934

8336729: C2: Div/Mod nodes without zero check could be split through iv phi of outer loop of long counted loop nest resulting in SIGFPE

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

! src/hotspot/share/opto/loopnode.hpp
! src/hotspot/share/opto/loopopts.cpp
! test/hotspot/jtreg/compiler/splitif/TestSplitDivisionThroughPhi.java

Changeset: 285ceb9e
Branch: premain
Author:    Vladimir Petko <vpetko at openjdk.org>
Date:      2024-08-20 15:51:40 +0000
URL:       https://git.openjdk.org/leyden/commit/285ceb9ee51e064687da6fc3fbed984e34cf02e6

8336529: (fs) UnixFileAttributeViews setTimes() failing on armhf, Ubuntu noble

Reviewed-by: bpb, alanb

! src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c

Changeset: c646efc3
Branch: premain
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-08-20 18:41:15 +0000
URL:       https://git.openjdk.org/leyden/commit/c646efc366342564baebd2f17133e14780abcaa8

8205957: setfldw001/TestDescription.java fails with bad field value

Reviewed-by: sspitsyn, dlong

! src/hotspot/share/runtime/javaCalls.cpp
! test/hotspot/jtreg/ProblemList-Xcomp.txt
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java

Changeset: 0267284c
Branch: premain
Author:    Mark Reinhold <mr at openjdk.org>
Date:      2024-08-20 18:50:17 +0000
URL:       https://git.openjdk.org/leyden/commit/0267284c52a450afaec78a542910381f5bff58fb

8338611: java.lang.module specification wording not aligned with JEP 261

Reviewed-by: alanb

! src/java.base/share/classes/java/lang/module/package-info.java

Changeset: 1ebf2cf6
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-08-20 19:02:38 +0000
URL:       https://git.openjdk.org/leyden/commit/1ebf2cf639300728ffc024784f5dc1704317b0b3

8336756: Improve ClassFile Annotation writing

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java

Changeset: d7281079
Branch: premain
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-08-20 23:34:31 +0000
URL:       https://git.openjdk.org/leyden/commit/d72810794bf70f82e46f7220698e4d27d5973d5b

8338482: com/sun/jdi/ThreadMemoryLeakTest.java requires that compressed oops are enabled

Reviewed-by: amenkov, kevinw

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

Changeset: 88ccbb60
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-08-21 01:05:41 +0000
URL:       https://git.openjdk.org/leyden/commit/88ccbb60919e4523064b0da17184eedcd9efa087

8336934: Clean up JavaLangReflectAccess

Reviewed-by: rriggs, darcy

! src/java.base/share/classes/java/lang/reflect/Constructor.java
! src/java.base/share/classes/java/lang/reflect/Method.java
! src/java.base/share/classes/java/lang/reflect/ReflectAccess.java
! src/java.base/share/classes/jdk/internal/access/JavaLangReflectAccess.java
! src/java.base/share/classes/jdk/internal/access/SharedSecrets.java
! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java

Changeset: cafb3dc4
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-08-21 07:04:05 +0000
URL:       https://git.openjdk.org/leyden/commit/cafb3dc49157daf12c1a0e5d78acca8188c56918

6318027: BasicScrollBarUI does not disable timer when enclosing frame is disabled.

Reviewed-by: abhiscxk, tr

! src/java.desktop/macosx/classes/com/apple/laf/AquaScrollBarUI.java
! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java
+ test/jdk/javax/swing/JScrollBar/DisableFrameFromScrollBar.java

Changeset: 59816975
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-21 08:17:01 +0000
URL:       https://git.openjdk.org/leyden/commit/598169756c903bb1f77e35ea32717043bc166e3c

8337828: CDS: Trim down minimum GC region alignment

Reviewed-by: iklam, phh

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

Changeset: e88a3b05
Branch: premain
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-08-21 08:19:35 +0000
URL:       https://git.openjdk.org/leyden/commit/e88a3b0574c0a6c6acb5faf7b67674d5b7f0797c

8338661: StackMapTable is invalid if frames appear in dead code

Reviewed-by: liach

! src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java
! test/jdk/jdk/classfile/StackMapsTest.java
! test/micro/org/openjdk/bench/jdk/classfile/CodeAttributeTools.java

Changeset: 715fa8f9
Branch: premain
Author:    Lutz Schmidt <lucy at openjdk.org>
Date:      2024-08-21 08:23:31 +0000
URL:       https://git.openjdk.org/leyden/commit/715fa8f9fe7242e86b985aece3d078b226f53fb9

8336498: [macos] [build]: install-file macro may run into permission denied error

Reviewed-by: clanger, erikj

! make/common/FileUtils.gmk

Changeset: c4cf1e93
Branch: premain
Author:    Gui Cao <gcao at openjdk.org>
Committer: Hamlin Li <mli at openjdk.org>
Date:      2024-08-21 08:58:40 +0000
URL:       https://git.openjdk.org/leyden/commit/c4cf1e93bb22bf7c65ce1943fff91f74839434df

8338539: New Object to ObjectMonitor mapping: riscv64 implementation

Reviewed-by: fyang, rehn, mli

! src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.hpp
! src/hotspot/cpu/riscv/interp_masm_riscv.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp
! src/hotspot/cpu/riscv/riscv.ad
! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp
! src/hotspot/share/runtime/basicLock.inline.hpp

Changeset: 7458952d
Branch: premain
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-08-21 10:17:51 +0000
URL:       https://git.openjdk.org/leyden/commit/7458952dedc0a34b5c7f3e9e228f9b18e08f19e3

8338595: Add more linesize for MIME decoder in macro bench test Base64Decode

Reviewed-by: rehn

! test/micro/org/openjdk/bench/java/util/Base64Decode.java

Changeset: 80adea8e
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-08-21 11:58:21 +0000
URL:       https://git.openjdk.org/leyden/commit/80adea8e0ab3753c3623267c6a2bd3eaed69ad29

8338545: Functional interface implementations for common pre-boot ClassFile operations

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
! src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java
! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedFieldBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/FieldImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/MethodImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java

Changeset: 918cf114
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-08-21 12:01:57 +0000
URL:       https://git.openjdk.org/leyden/commit/918cf114548d0098cf6a8a50032b78ee04d453db

8338490: Serial: Move Generation::print_on to subclasses

Reviewed-by: gli

! src/hotspot/share/gc/serial/defNewGeneration.cpp
! src/hotspot/share/gc/serial/defNewGeneration.hpp
! src/hotspot/share/gc/serial/generation.cpp
! src/hotspot/share/gc/serial/generation.hpp
! src/hotspot/share/gc/serial/serialHeap.cpp
! src/hotspot/share/gc/serial/tenuredGeneration.cpp
! src/hotspot/share/gc/serial/tenuredGeneration.hpp

Changeset: 3aeb6733
Branch: premain
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-08-21 14:56:30 +0000
URL:       https://git.openjdk.org/leyden/commit/3aeb6733f958bc2b0132494b8ac51a4cfa6b98de

8338532: Speed up the ClassFile API MethodTypeDesc#ofDescriptor

Reviewed-by: redestad, liach

! src/java.base/share/classes/java/lang/constant/ClassDesc.java
! src/java.base/share/classes/java/lang/constant/ConstantDescs.java
! src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java
! src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java
! src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java
! src/java.base/share/classes/jdk/internal/constant/PrimitiveClassDescImpl.java
! src/java.base/share/classes/jdk/internal/constant/ReferenceClassDescImpl.java
! src/java.base/share/classes/sun/invoke/util/Wrapper.java
! test/jdk/java/lang/constant/boottest/java.base/jdk/internal/constant/ConstantUtilsTest.java
! test/micro/org/openjdk/bench/java/lang/constant/MethodTypeDescFactories.java
! test/micro/org/openjdk/bench/java/lang/invoke/Wrappers.java

Changeset: 0e8fe355
Branch: premain
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-08-21 15:11:32 +0000
URL:       https://git.openjdk.org/leyden/commit/0e8fe3550b628c6617ac7593d7e17ef7d9bc0869

8338677: Improve startup of memory access var handles by simplifying combinator chains

Reviewed-by: redestad

! src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template
! src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
! src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java
! src/java.base/share/classes/jdk/internal/foreign/Utils.java

Changeset: e297e881
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-21 16:10:41 +0000
URL:       https://git.openjdk.org/leyden/commit/e297e8817f486e4af850c97fcff859c3e9a9e21c

8338688: Shenandoah: Avoid calling java_lang_Class accessors in asserts/verifier

Reviewed-by: rkennke, wkemper

! src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp

Changeset: ab8071d2
Branch: premain
Author:    Doug Lea <dl at openjdk.org>
Date:      2024-08-21 18:22:24 +0000
URL:       https://git.openjdk.org/leyden/commit/ab8071d28027ecbf5e8984c30b35fa1c2d934de7

8338146: Improve Exchanger performance with VirtualThreads

Reviewed-by: alanb

! src/java.base/share/classes/java/util/concurrent/Exchanger.java
! src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java
! src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java

Changeset: 47c8a6a8
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-08-21 22:10:06 +0000
URL:       https://git.openjdk.org/leyden/commit/47c8a6a8db979fe862be876008feb76cdc9dccfd

8333265: De-duplicate method references in java.util.stream.FindOps

Reviewed-by: liach

! src/java.base/share/classes/java/util/stream/FindOps.java
! test/micro/org/openjdk/bench/java/util/stream/ops/ref/FindAny.java

Changeset: 1d05989b
Branch: premain
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2024-08-22 06:23:06 +0000
URL:       https://git.openjdk.org/leyden/commit/1d05989bb4bcc08ef6f7c408ec987ea43995eb07

8334357: Use NonInterleavingLogStream for report_metadata_oome

Reviewed-by: jsjolen, stuefe

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

Changeset: 6644dd33
Branch: premain
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-08-22 07:22:35 +0000
URL:       https://git.openjdk.org/leyden/commit/6644dd33f6f4b440105d84ef187a0ff6b1d60827

8338760: Adjust the comment after UseObjectMonitorTable

Reviewed-by: coleenp, dcubed

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

Changeset: 129f527f
Branch: premain
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-08-22 10:31:34 +0000
URL:       https://git.openjdk.org/leyden/commit/129f527f4f6de04897440a11f0be024f1a378433

8338290: Xcode project generator for hotspot

Co-authored-by: Gerard Ziemski <gziemski at openjdk.org>
Co-authored-by: Magnus Ihse Bursie <ihse at openjdk.org>
Reviewed-by: azafari, erikj

! make/Main.gmk
! make/common/FileUtils.gmk
! make/common/NativeCompilation.gmk
! make/common/native/Link.gmk
! make/ide/visualstudio/hotspot/CreateVSProject.gmk
+ make/ide/xcode/hotspot/CreateXcodeProject.gmk
+ make/ide/xcode/hotspot/data/Breakpoints_v2.xcbkptlist.template
+ make/ide/xcode/hotspot/data/jvm.xcscheme.template
+ make/ide/xcode/hotspot/data/project.pbxproj.template
+ make/ide/xcode/hotspot/data/runJ2Demo.xcscheme.template
+ make/ide/xcode/hotspot/data/script_after.sh
+ make/ide/xcode/hotspot/data/script_before.sh
+ make/ide/xcode/hotspot/src/classes/DiskFile.java
+ make/ide/xcode/hotspot/src/classes/XcodeProjectMaker.java
! make/modules/java.base/Copy.gmk

Changeset: 6cf7f9c4
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-22 11:39:47 +0000
URL:       https://git.openjdk.org/leyden/commit/6cf7f9c4a76b99ed7aa4dc7ee54692331fc73408

8338662: Shenandoah: Remove excessive ShenandoahVerifier::verify_during_evacuation

Reviewed-by: wkemper, ysr

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.hpp

Changeset: 6041c936
Branch: premain
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-08-22 15:55:02 +0000
URL:       https://git.openjdk.org/leyden/commit/6041c936d6dd39c5b3a89ed2823b25a8aef42b9f

8335664: Parsing jsr broken: assert(bci>= 0 && bci < c->method()->code_size()) failed: index out of bounds

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

! src/hotspot/share/oops/generateOopMap.cpp
+ test/hotspot/jtreg/runtime/interpreter/LastJsr.jasm
+ test/hotspot/jtreg/runtime/interpreter/LastJsrReachable.jasm
+ test/hotspot/jtreg/runtime/interpreter/LastJsrTest.java

Changeset: 0b5c8870
Branch: premain
Author:    Matthew Donovan <mdonovan at openjdk.org>
Date:      2024-08-22 17:58:08 +0000
URL:       https://git.openjdk.org/leyden/commit/0b5c8870e5aa4fd0889d60faa9b1f65a9c338fff

8338380: Update TLSCommon/interop/AbstractServer to specify an interface to listen for connections

Reviewed-by: rhalade

! test/jdk/javax/net/ssl/TLSCommon/interop/AbstractServer.java
! test/jdk/javax/net/ssl/TLSCommon/interop/JdkServer.java

Changeset: 813546f9
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-08-22 19:48:25 +0000
URL:       https://git.openjdk.org/leyden/commit/813546f9236d278c380888f1f90cd49b23792d92

8338856: [BACKOUT] JDK-8337828: CDS: Trim down minimum GC region alignment

Reviewed-by: dcubed

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

Changeset: c89a1c35
Branch: premain
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2024-08-22 21:41:25 +0000
URL:       https://git.openjdk.org/leyden/commit/c89a1c35bda9002ee687b3fa267f3ef9cba78b00

8338696: (fs) BasicFileAttributes.creationTime() falls back to epoch if birth time is unavailable (Linux)

Reviewed-by: sgehwolf, alanb

! src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c

Changeset: 06f6f57b
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-22 15:20:14 +0000
URL:       https://git.openjdk.org/leyden/commit/06f6f57b85a7fc0a5af2041dfa9f5760e50ebeec

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

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
! src/hotspot/cpu/s390/stubGenerator_s390.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/cds/archiveHeapWriter.hpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/heapShared.hpp
! src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/compiler/compilationPolicy.hpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/logging/logTag.hpp
! src/hotspot/share/memory/metaspace.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/parse.hpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/init.cpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/javaThread.inline.hpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/sharedRuntime.hpp
! src/hotspot/share/runtime/stubRoutines.cpp
! src/hotspot/share/runtime/stubRoutines.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
! src/hotspot/cpu/s390/stubGenerator_s390.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/cds/archiveHeapWriter.hpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/heapShared.hpp
+ src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/compiler/compilationPolicy.hpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/logging/logTag.hpp
! src/hotspot/share/memory/metaspace.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/parse.hpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/init.cpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/javaThread.inline.hpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/sharedRuntime.hpp
! src/hotspot/share/runtime/stubRoutines.cpp
! src/hotspot/share/runtime/stubRoutines.hpp
! src/hotspot/share/runtime/vmStructs.cpp

Changeset: 2d15c193
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-22 18:32:20 +0000
URL:       https://git.openjdk.org/leyden/commit/2d15c1933b36efc78aa3ffc31aca52e7317ef196

temp work-around to get premain to work with JDK-8338532 and JDK-8336856; todo -- fix this more properly

! src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp
! src/hotspot/share/cds/classPreinitializer.cpp
! src/hotspot/share/cds/lambdaFormInvokers.cpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp

Changeset: a371fddb
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-22 18:32:26 +0000
URL:       https://git.openjdk.org/leyden/commit/a371fddb74dd1fbf10da5ead2584723e083cb8cd

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

! src/hotspot/share/cds/heapShared.hpp
! src/hotspot/share/cds/heapShared.hpp


From dan.heidinga at oracle.com  Fri Aug 23 13:53:18 2024
From: dan.heidinga at oracle.com (Dan Heidinga)
Date: Fri, 23 Aug 2024 13:53:18 +0000
Subject: EA feedback
In-Reply-To: <BL4PR21MB41283FFEC5120462CF5129368A8F2@BL4PR21MB4128.namprd21.prod.outlook.com>
References: <CAABjz10oAmoLkEfLSLo0MN7+BzCFQJ5VYSkmhWH6GB6SVrF57Q@mail.gmail.com>
 <CAKt0pySHtZHSk0FyarM7kkdygTBppHBcYfpXPOfiJuS+7qjQyg@mail.gmail.com>
 <bcf26ac8-663f-4b11-abb3-1ca942d506e2@oracle.com>
 <A0C193BF-B8DB-4BC6-95D5-BBA21DC92F27@oracle.com>
 <BL4PR21MB41283FFEC5120462CF5129368A8F2@BL4PR21MB4128.namprd21.prod.outlook.com>
Message-ID: <DS0PR10MB627145CC00B9318C3B728697E7882@DS0PR10MB6271.namprd10.prod.outlook.com>

For some background on my thinking here:  There are two extremes here I?d like to avoid ? the first is ?clean exit is the only way to stop training?, and the second is the ?the more the merrier? configuration extreme.  I think we?re already moving away from the first (good!) but I don?t want us to move so far away we run into the second.  I have a lot of OpenJ9 experience which had two great tools for hooking into system events ? the dump and trace apis.  Unfortunately, they both had grown all manner of bells and whistles that required webapps to generate the required set of options.  Great tool ? terrible UX.  All that to say I?m somewhat hesitant of being too configurable.

My preference is to build the minimum hooks into the runtime that allow *external* processes to trigger the end of training.  John?s proposal to use a breakpoint-like mechanism spells out the runtime internals of one such mechanism to support an external process (config file, command line, api  or jcmd) triggering the ?end-training? signal.

Can we spin the two new requests as being part of such an external process?  Are they more naturally VM primitives?

--Dan

From: leyden-dev <leyden-dev-retn at openjdk.org> on behalf of Mat Carter <Matthew.Carter at microsoft.com>
Date: Thursday, August 22, 2024 at 12:04?PM
To: John Rose <john.r.rose at oracle.com>, Ioi Lam <ioi.lam at oracle.com>
Cc: leyden-dev at openjdk.org <leyden-dev at openjdk.org>
Subject: Re: EA feedback
Having considered the JBS issue [1], we'd like to propose/discuss some additional options, the thought being that while implementation can be staggered it might be helpful to consider them now to help prioritize/rethink/reject.

In summary we currently have the "stop" action, stopping is immediate (now) and operationalized via the following mechanisms:
??????? Ctrl-Z/D
??????? System.Exit()
??????? Run to completion (normal termination)
??????? Unhandled exception :)

And this new ask in JBS [1] is to
??????? Add a mechanism using 'jcmd' and/or a new Leyden API to action the existing "stop" (now) functionality
??????? Add a variant of the "stop" action where training stops when execution enters a java method (optionally after N invocations); specify method to stop on via Command Line (-XX), JCmd and/or Leyden API

We?d like to propose two additional variants to aid with stopping training runs:
??????? Stop training after some time has elapsed
??????? Stop training when some threshold is met

The second point comes from considering the definition of 'startup complete' and 'warmup complete'.  Considering the developer is already engaged in AOT training, we should allow the developer to aid the training by:
??????? Indicating when the application has completed startup (ready to work)
??????? Indicate when the application has completed warmup, either by:
????????????? Calling an API to indicate warmup is done
????????????? Calling an API when a chunk of work has completed, passing in the 'duration'; this 'duration' is compared to some specified 'threshold' to generate the 'warmup is complete' event

Adding a threshold means that training runs can be of optimal length and can handle changes in the environment and/or code.  Coupled with maybe an "abort training" action we now have a training run that targets a threshold and aborts if not reached in time N.

Currently we have the command line, jcmd and a new Leyden API to support training runs.  Lastly we'd like to propose a fourth method that being an MxBean (uses the new Leyden API); this would allow the developer to provide the startup and warmup indicators internally or externally (their choice), and would allow for runtime analysis using bespoke production systems or JMC, and offline analysis via JFR.

Cheers
Mat

[1] https://bugs.openjdk.org/browse/JDK-8335358

From: leyden-dev <leyden-dev-retn at openjdk.org> on behalf of John Rose <john.r.rose at oracle.com>
Date: Friday, August 16, 2024 at 4:51 PM
To: ioi.lam at oracle.com <ioi.lam at oracle.com>
Cc: leyden-dev at openjdk.org <leyden-dev at openjdk.org>
Subject: Re: EA feedback

Here?s the way I would prefer to think about a ?dump command?.

The native way that the JVM represents sequential operations is
the method. Talking about methods is therefore a basic way to
specify a condition for injecting a JVM operation like training
dumps. I would like to figure out a good way to tie the training
dump to the invocation of a method, either a single well-known
method, or to a method specified (on the command line) by the
user.

In fact, it feels like a breakpoint-like operation would be a
natural way to view the training dump. You don?t need JVMTI
to get it done; you just need a hack in the VM which parallels
the existing breakpoint mechanism, but special-cases it to
drive a training dump.

Given such a foundation, jsig could then inject a call to a
method which is appropriately tied to the dump command.

Sketch of implementation:

When a method is first linked, a list is checked to see if
it has a dump event tied to it, and a bit is set on the method.
The method?s interpreter entry point might be modified, or
perhaps the interpreter just always checks the bit. On entry
to the method, before the first bytecode, an upcall tells
the VM that it?s time to finish the training run.

The compilers also check this bit, of course.

There is some method deep in the privates of java.base
that is always treated this way. That?s what jcmd reaches.
There is a command line option which lists more methods
to treat this way, something like the CompileOnly command.

As a separate option, the upcall to end the training run
might return (allowing the VM to continue) or just exit.

As a separate option, allow the user to specify a count N,
so that the training dump happens only after N ?hits? on
any marked method(s).

I think all this is useful and flexible.

On 13 Aug 2024, at 18:22, ioi.lam at oracle.com wrote:


On 8/13/24 12:42 PM, Ashutosh Mehra wrote:
Being able to trigger assembly/verification via jcmd without exiting, would make this far easier for us to support.

There is a proposed enhancement for doing exactly this (and exploring other ways to trigger end of training run); see https://bugs.openjdk.org/browse/JDK-8335358



I am working on a prototype for dumping with jcmd. It will be similar to the existing "jcmd VM.cds statoc_dump" command, except that it will also support the dumping of the AOT cache and profile data.



Thanks

- Ioi



Thanks,
- Ashutosh Mehra


On Fri, Aug 9, 2024 at 4:38?PM Danny Thomas <dannyt at netflix.com<mailto:dannyt at netflix.com>> wrote:
I tried 24-leydenpremain+2-8 on a few internal applications, some quick feedback below (good to see you folks at the JVM LS!).

If a jar has a Class-Path attribute and one or more of those libraries are explicitly on the classpath, it causes the actual and expected classpath to always differ. This is also the case currently with CDS of course, but this feature is sure to be deployed far more broadly than CDS is currently, so likely something you want to look at:

[0.057s][info][class,path] non-existent Class-Path entry lib/failureaccess-1.0.1.jar
[0.057s][info][class,path] opened: lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
[0.057s][info][class,path] library = lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar

Startup time when training seems to be on par with ArchiveClassesAtExit in JDK 21, but it's about a 3.5x startup time penalty for one of our typical Spring Boot applications. From a back-to-back run on my machine (AMD EPYC 9R14, 32 cores, 123G, Ubuntu 22.04.4 LTS):

Started App in 7.698 seconds (process running for 8.229)
Started App in 26.247 seconds (process running for 29.262) - w/ CacheDataStore, Training Run
Started App in 4.341 seconds (process running for 4.917)  - w/ CacheDataStore, Production Run

I also got a crash on one attempt, I can't remember what I did to cause this unfortunately:

Stack: [0x00007f3949ab0000,0x00007f3949bb0000],  sp=0x00007f3949bae628,  free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x42ca30]  ArchiveBuilder::get_buffered_addr(unsigned char*) const+0x40
V  [libjvm.so+0xce4aa5]  VM_PopulateDumpSharedSpace::doit()+0x395
V  [libjvm.so+0x100ae69]  VM_Operation::evaluate()+0x109
V  [libjvm.so+0x100e348]  VMThread::evaluate_operation(VM_Operation*)+0xe8
V  [libjvm.so+0x10142fb]  VMThread::inner_execute(VM_Operation*)+0x35b
V  [libjvm.so+0x101460f]  VMThread::run()+0x16f
V  [libjvm.so+0xf6e5cf]  Thread::call_run()+0x9f
V  [libjvm.so+0xd74e13]  thread_native_entry(Thread*)+0x183
C  [libc.so.6+0x98b07]

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000030
Thinking ahead to operationalizing AOT, while a single-shot/on-exit workflow is great for iterating locally, requiring the VM to exit makes this more difficult to operationalize at scale:
1.    We'll perform training and assembly on test, production canary and production instances on behalf of application owners and handle distribution of the archives. Depending on when we're able to perform a training run, it'll have different benefits. i.e.:
1.    Test environment will at least improve startup performance, with a mixed benefit for warm up depending on the kind of traffic they take in test
2.    If an application uses canary deployments we'll have a full production profile prior to the full production deployment, and all instances will come up hot
3.    If we reach production with only a test environment profile, we'll perform a training run in production, so instances that scale up following that run will come up hot (completely cold instances for an initial deployment is less of a concern, because we deploy immutably and get a natural warm-up period while we have 200% capacity online for a cluster)
2.    It's currently not a problem if a VM doesn't exit completely due to a dangling non-daemon thread or hung shutdown hook
Being able to trigger assembly/verification via jcmd without exiting, would make this far easier for us to support. If the overhead of the instrumentation for CDS can be avoided, being able to take a snapshot at any time on any VM would be better still, but that wouldn't be an impediment for us: we'll know that the instance will be used for training at boot time.

We build nightlies of all the currently active OpenJDK projects, so if you land anything on premain between EA builds that you'd like us to try, let us know!

Cheers,
Danny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240823/d34c621a/attachment.htm>

From duke at openjdk.org  Fri Aug 23 19:43:29 2024
From: duke at openjdk.org (duke)
Date: Fri, 23 Aug 2024 19:43:29 GMT
Subject: git: openjdk/leyden: premain: Keep cached strings longer. Fix
 ExternalsRecorder::print_statistics()
Message-ID: <97d0fd71-429a-4b2b-90c1-d5b7bce73836@openjdk.org>

Changeset: 7f633b95
Branch: premain
Author:    Vladimir Kozlov <vladimir.kozlov at oracle.com>
Date:      2024-08-23 12:41:39 +0000
URL:       https://git.openjdk.org/leyden/commit/7f633b95c03ff824fbb243f5b463a25682d061d8

Keep cached strings longer. Fix ExternalsRecorder::print_statistics()

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


From Divino.Cesar at microsoft.com  Fri Aug 23 22:04:23 2024
From: Divino.Cesar at microsoft.com (Cesar Soares Lucas)
Date: Fri, 23 Aug 2024 22:04:23 +0000
Subject: Some offhand questions
Message-ID: <MN2PR21MB1520FB8265FD2801AD126EBB9A882@MN2PR21MB1520.namprd21.prod.outlook.com>

Hello!

I've a few questions that I'd like to ask your opinion about.

- Signed Jars: As far as I understand, we currently don't include classes from signed jars in the CDS archive. What is the reason for that? I had the impression that being able to archive such classes would be important given that many .jars are signed?!

- Profile/Archive score: I've been thinking that maybe a profile/archive score would be something useful to have at some point. The goal with such a "score" would be to report back to the user how much information from the archive was effectively used during a production run so that they have some insight about how "good" was the training run used to create the archive. The score for an archive could be an [weighted] aggregate of the scores of specific parts of the archive. We could also use the scores, in the future, if we choose to work on something to "merge" or "combine" multiple archives.

- Condensers: I've been asked recently about the idea of condensers. As far as I understand there is nothing implemented on the lines of that idea. Is this something that we still plan to work in the future?

- Recompilation: I've been reviewing the changes in the @premain branch, and I came across this piece of code [1] and was puzzled by it. Why do we recompile the code at every compilation level? There is a lot I still don't understand about the implementation in premain, but what I was expecting was that at some point in the code we would just "dump" the code cache and that would be our "AOT compiled code".


Thanks,
Cesar

[1] https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/compiler/precompiler.cpp#L234

From alan.bateman at oracle.com  Sat Aug 24 14:21:28 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sat, 24 Aug 2024 15:21:28 +0100
Subject: Some offhand questions
In-Reply-To: <MN2PR21MB1520FB8265FD2801AD126EBB9A882@MN2PR21MB1520.namprd21.prod.outlook.com>
References: <MN2PR21MB1520FB8265FD2801AD126EBB9A882@MN2PR21MB1520.namprd21.prod.outlook.com>
Message-ID: <36ff7b53-e898-48b6-952a-7e6ce284ef18@oracle.com>



On 23/08/2024 23:04, Cesar Soares Lucas wrote:
> Hello!
>
> I've a few questions that I'd like to ask your opinion about.
>
> - Signed Jars: As far as I understand, we currently don't include classes from signed jars in the CDS archive. What is the reason for that? I had the impression that being able to archive such classes would be important given that many .jars are signed?!
>
As a general point, signed JARs on the class path or module path aren't 
all that useful. It's very different to a signed JAR loaded from a 
remote site where the JDK would need a lot more infrastructure to 
validation certificate chains. There has been consideration on and off 
for many years about dropping the support for JAR files on the class 
path (and module path). The nice thing about dropping this (only from 
the class path and module path) is that it would avoid executing a lot 
of problematic security code when open JAR files.

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

From raymondmeester at gmail.com  Sun Aug 25 16:07:27 2024
From: raymondmeester at gmail.com (ski n)
Date: Sun, 25 Aug 2024 18:07:27 +0200
Subject: Windows build of Leyden EA
Message-ID: <CABKVO1X1Qd2jxSYZ+s6z6jt92n6ovBw90N_AQDaWbf9+-Kj1gg@mail.gmail.com>

I just watched the presentation at JVMLS on the status of project Leyden on
YouTube:

https://www.youtube.com/watch?v=OOPSU4LnKg0

In the talk, they pointed at the EA that came out last June. Currently,
only Linux and Mac builds are available.

When will the next EA come available, and will this also contain a Windows
build?

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

From dan.heidinga at oracle.com  Mon Aug 26 13:25:56 2024
From: dan.heidinga at oracle.com (Dan Heidinga)
Date: Mon, 26 Aug 2024 13:25:56 +0000
Subject: Some offhand questions
In-Reply-To: <MN2PR21MB1520FB8265FD2801AD126EBB9A882@MN2PR21MB1520.namprd21.prod.outlook.com>
References: <MN2PR21MB1520FB8265FD2801AD126EBB9A882@MN2PR21MB1520.namprd21.prod.outlook.com>
Message-ID: <DS0PR10MB6271ABD27C0668797F4FCC35E78B2@DS0PR10MB6271.namprd10.prod.outlook.com>

> - Profile/Archive score: I've been thinking that maybe a profile/archive score would be something useful to have at some
> point. The goal with such a "score" would be to report back to the user how much information from the archive was
> effectively used during a production run so that they have some insight about how "good" was the training run used to
> create the archive. The score for an archive could be an [weighted] aggregate of the scores of specific parts of the archive.
> We could also use the scores, in the future, if we choose to work on something to "merge" or "combine" multiple archives.

There are two things I can think of that may be interesting to track  that shouldn?t be too expensive:
- how many of the AOTCache preloaded classes get initialized in a given production run as a proxy for how applicable the preloaded / prelinked class base is
- how many of the AOTCache aot?d methods are used in the a given run.

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

> - Condensers: I've been asked recently about the idea of condensers. As far as I understand there is nothing implemented
>  on the lines of that idea. Is this something that we still plan to work in the future?

The premain efforts have been our primary area of investigation given the unreasonable effectiveness of training runs.  Observing the application and optimizing based on those observations fits naturally with the rest of the Hotspot design ? after all, Hotspot is named for observing programs to find the most profitable areas (?hot spots?) to compile.  There are actually a lot overlap between what can be done with the two techniques ? for example, I wrote a prototype to replace the runtime LambdaMetaFactory class generation with statically generated classes but found a long tail of behaviour differences (hidden vs non-hidden classes, stack trace differences, nest members, etc).  Training runs can also pre-generate the lambda classes using the LambdaMetaFactory and doing so avoids that long tail of behaviour differences.

Condensers are an area we may come back to more in the future as there are other problems ? class path scanning for one ? that can be optimized statically without the behaviour difference bug tail.

--Dan

From: leyden-dev <leyden-dev-retn at openjdk.org> on behalf of Cesar Soares Lucas <Divino.Cesar at microsoft.com>
Date: Friday, August 23, 2024 at 6:09?PM
To: Leyden-dev Maillist <leyden-dev at openjdk.org>
Cc: Brian Stafford <Brian.Stafford at microsoft.com>, Mat Carter <Matthew.Carter at microsoft.com>
Subject: Some offhand questions
Hello!

I've a few questions that I'd like to ask your opinion about.

- Signed Jars: As far as I understand, we currently don't include classes from signed jars in the CDS archive. What is the reason for that? I had the impression that being able to archive such classes would be important given that many .jars are signed?!

- Profile/Archive score: I've been thinking that maybe a profile/archive score would be something useful to have at some point. The goal with such a "score" would be to report back to the user how much information from the archive was effectively used during a production run so that they have some insight about how "good" was the training run used to create the archive. The score for an archive could be an [weighted] aggregate of the scores of specific parts of the archive. We could also use the scores, in the future, if we choose to work on something to "merge" or "combine" multiple archives.

- Condensers: I've been asked recently about the idea of condensers. As far as I understand there is nothing implemented on the lines of that idea. Is this something that we still plan to work in the future?

- Recompilation: I've been reviewing the changes in the @premain branch, and I came across this piece of code [1] and was puzzled by it. Why do we recompile the code at every compilation level? There is a lot I still don't understand about the implementation in premain, but what I was expecting was that at some point in the code we would just "dump" the code cache and that would be our "AOT compiled code".


Thanks,
Cesar

[1] https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/compiler/precompiler.cpp#L234
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240826/4ab68098/attachment.htm>

From ioi.lam at oracle.com  Mon Aug 26 21:01:39 2024
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 26 Aug 2024 21:01:39 +0000
Subject: Some offhand questions
In-Reply-To: <36ff7b53-e898-48b6-952a-7e6ce284ef18@oracle.com>
References: <MN2PR21MB1520FB8265FD2801AD126EBB9A882@MN2PR21MB1520.namprd21.prod.outlook.com>
 <36ff7b53-e898-48b6-952a-7e6ce284ef18@oracle.com>
Message-ID: <SA1PR10MB58853F8FAEAE325F060D4CF2828B2@SA1PR10MB5885.namprd10.prod.outlook.com>

Many apps used signed jars "accidentally". When signed jars were fashionable, some lib developers signed their jars. Many of these libraries become orphaned and remain signed for no particular reason.

The reason that CDS doesn't archive signed classes is because we aren't sure if we skip the whole signature checking process at run time, we can still ensure that all APIs related to code signing (eg Class.getSigners) can return the expected value.

Cesar, could you confirm if the class signatures are actually used for something useful?

If not, I think maybe we can introduce a new execution mode, to simply ignore code signatures.

Or drop support for signed jars as Alan mentioned below.

Thanks
Ioi



-----------

 From: leyden-dev <leyden-dev-retn at openjdk.org> on behalf of Alan Bateman <alan.bateman at oracle.com>
Sent: Saturday, August 24, 2024 7:23 AM
To: Cesar Soares Lucas <Divino.Cesar at microsoft.com>; Leyden-dev Maillist <leyden-dev at openjdk.org>
Cc: Brian Stafford <Brian.Stafford at microsoft.com>; Mat Carter <Matthew.Carter at microsoft.com>
Subject: Re: Some offhand questions



On 23/08/2024 23:04, Cesar Soares Lucas wrote:

Hello!

I've a few questions that I'd like to ask your opinion about.

- Signed Jars: As far as I understand, we currently don't include classes from signed jars in the CDS archive. What is the reason for that? I had the impression that being able to archive such classes would be important given that many .jars are signed?!



As a general point, signed JARs on the class path or module path aren't all that useful. It's very different to a signed JAR loaded from a remote site where the JDK would need a lot more infrastructure to validation certificate chains. There has been consideration on and off for many years about dropping the support for JAR files on the class path (and module path). The nice thing about dropping this (only from the class path and module path) is that it would avoid executing a lot of problematic security code when open JAR files.

-Alan


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

From duke at openjdk.org  Mon Aug 26 21:23:38 2024
From: duke at openjdk.org (duke)
Date: Mon, 26 Aug 2024 21:23:38 GMT
Subject: git: openjdk/leyden: premain: Cleanup AOT runtime constants code
Message-ID: <b60c2f2d-0af5-4f68-a9cc-eab47a98cab0@openjdk.org>

Changeset: cc111760
Branch: premain
Author:    Vladimir Kozlov <vladimir.kozlov at oracle.com>
Date:      2024-08-26 14:21:28 +0000
URL:       https://git.openjdk.org/leyden/commit/cc111760a0dd123935e039feb19eaac742f865b2

Cleanup AOT runtime constants code

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/adlc/main.cpp
! src/hotspot/share/ci/ciUtilities.cpp
! src/hotspot/share/ci/ciUtilities.hpp
! src/hotspot/share/code/SCCache.hpp
! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp
! src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp
! src/hotspot/share/gc/shared/barrierSet.hpp
! src/hotspot/share/runtime/stubRoutines.hpp


From alan.bateman at oracle.com  Tue Aug 27 06:36:32 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 27 Aug 2024 07:36:32 +0100
Subject: Some offhand questions
In-Reply-To: <SA1PR10MB58853F8FAEAE325F060D4CF2828B2@SA1PR10MB5885.namprd10.prod.outlook.com>
References: <MN2PR21MB1520FB8265FD2801AD126EBB9A882@MN2PR21MB1520.namprd21.prod.outlook.com>
 <36ff7b53-e898-48b6-952a-7e6ce284ef18@oracle.com>
 <SA1PR10MB58853F8FAEAE325F060D4CF2828B2@SA1PR10MB5885.namprd10.prod.outlook.com>
Message-ID: <894c7ba3-6d4f-4473-b6fc-a90dad9f902b@oracle.com>

On 26/08/2024 22:01, Ioi Lam wrote:
> *:*
> *
> *
> *The reason that CDS doesn't archive signed classes is because we 
> aren't sure if we skip the whole signature checking process at run 
> time, we can still ensure that all APIs related to code signing (eg 
> Class.getSigners) can return the expected value.*
>
Just to add add that this was an issue when jlink was introduced in JDK 
9 too. There was exploration into persisting the signer information into 
the runtime image so that signer information is available at runtime if 
needed. In the end, it didn't go too far and jlink now errors if you 
attempt to link in a module that is signed, need to use 
--ignore-signing-information to drop the signer information at link time.

Probably time to have another go as dropping signed JAR support from the 
class path and module path as it's too troublesome and don't do what 
people think.

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

From sgehwolf at redhat.com  Tue Aug 27 09:25:10 2024
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 27 Aug 2024 11:25:10 +0200
Subject: Some offhand questions
In-Reply-To: <894c7ba3-6d4f-4473-b6fc-a90dad9f902b@oracle.com>
References: <MN2PR21MB1520FB8265FD2801AD126EBB9A882@MN2PR21MB1520.namprd21.prod.outlook.com>
 <36ff7b53-e898-48b6-952a-7e6ce284ef18@oracle.com>
 <SA1PR10MB58853F8FAEAE325F060D4CF2828B2@SA1PR10MB5885.namprd10.prod.outlook.com>
 <894c7ba3-6d4f-4473-b6fc-a90dad9f902b@oracle.com>
Message-ID: <dd91f246e7a2fdc70cfa5af57b8cd9077fd09dd9.camel@redhat.com>

On Tue, 2024-08-27 at 07:36 +0100, Alan Bateman wrote:
> Probably time to have another go as dropping signed JAR support from
> the class path and module path as it's too troublesome and don't do
> what people think.

+1

Thanks,
Severin


From sanne at redhat.com  Tue Aug 27 10:12:03 2024
From: sanne at redhat.com (Sanne Grinovero)
Date: Tue, 27 Aug 2024 11:12:03 +0100
Subject: Some offhand questions
In-Reply-To: <dd91f246e7a2fdc70cfa5af57b8cd9077fd09dd9.camel@redhat.com>
References: <MN2PR21MB1520FB8265FD2801AD126EBB9A882@MN2PR21MB1520.namprd21.prod.outlook.com>
 <36ff7b53-e898-48b6-952a-7e6ce284ef18@oracle.com>
 <SA1PR10MB58853F8FAEAE325F060D4CF2828B2@SA1PR10MB5885.namprd10.prod.outlook.com>
 <894c7ba3-6d4f-4473-b6fc-a90dad9f902b@oracle.com>
 <dd91f246e7a2fdc70cfa5af57b8cd9077fd09dd9.camel@redhat.com>
Message-ID: <CAA5_-WaxzZ1zXmFjG7sfCeiU2RJ_SamYCcAV8RBiwD+sfZ452A@mail.gmail.com>

On Tue, Aug 27, 2024 at 10:25?AM Severin Gehwolf <sgehwolf at redhat.com>
wrote:

> On Tue, 2024-08-27 at 07:36 +0100, Alan Bateman wrote:
> > Probably time to have another go as dropping signed JAR support from
> > the class path and module path as it's too troublesome and don't do
> > what people think.
>
> +1
>

+1 as well, from a point of view of Quarkus we also observed much overhead
with signed JARs, a cost that comes with unclear benefits.

I hoped to skip such processing in our custom classloaders for efficiency
reasons, but doing this solely at our layer w/o endorsement of the JDK is
problematic; part of this is implementation related, a little tricky to do,
but primarily I backed off as I didn't feel comfortable in taking away this
capability from our users w/o being able to point to an authority like Alan
stating here clearly that it's "not that useful".

I'd be happy to see it fully dropped, but if that can't be done quickly,
I'd also be happy to use an opt-in flag to get this moving and foster rapid
feedback. We would have frameworks like Quarkus set such a flag by default,
advertise this change in our communities and let you know of any complaints.

Thanks,
Sanne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240827/3817b0a9/attachment.htm>

From john.r.rose at oracle.com  Tue Aug 27 16:49:34 2024
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 27 Aug 2024 09:49:34 -0700
Subject: Encapsulating JVM Options
In-Reply-To: <MN2PR21MB15206C7663A2A91F239D79E19A882@MN2PR21MB1520.namprd21.prod.outlook.com>
References: <CH2PR21MB151167D4A0854C44EFC98E579A8C2@CH2PR21MB1511.namprd21.prod.outlook.com>
 <1C91B949-D3BA-49DB-A3C0-C2FBDB51BE94@oracle.com>
 <3AA8412F-CB31-4DA0-8105-29979B300480@oracle.com>
 <MN2PR21MB15206C7663A2A91F239D79E19A882@MN2PR21MB1520.namprd21.prod.outlook.com>
Message-ID: <9DF94F77-5292-40FE-B258-9BA4E3C35E21@oracle.com>

[CC-ing leyden-dev for this reply.  We are talking about ways to wire
up dependencies on JVM options in globals.hpp and elsewhere to the
AOT cache as a whole, and/or to individually compiled nmethods.]

On 23 Aug 2024, at 10:21, Cesar Soares Lucas wrote:

> Hi, Igor, John.
>
> Some questions:
>
>> From John Rose
>> This should probably turn into a
>> dependency record (of some sort) on the particular AOT nmethod, so that
>> when we load AOT code in production, we can ensure we are not loading
>> a method that ?doesn?t fit? into the current JVM.
>
> John, you mentioned above adding the "dependency record" to a particular _nmethod_. I was under the impression that the record would be the same for all HotSpot components (or a single record for the whole CDS archive). Do you think we might need (or want) different records (or parts of it) for different HotSpot components, compilation tasks, or nmethods?

I have been using the term ?dependency record? loosely, because such a
thing can be appropriate on the AOT cache as a whole, or on specific ?assets?
that are optionally loadable within the AOT cache, and specifically nmethods
or other code blobs.  (As you know, code blobs reside in the ?code cache?,
aka the code heap.  An nmethod is a code blob that compiles the entry point
of some Java/JVM method.)  Nmethods in the AOT code cache are by nature
optionally adoptable, since you can always ignore it and use some other
mode for executing the corresponding Java/JVM method.

(Note:  AOT cache is the new name for the CDS archive, as expanded by
the new features we are working on.  In our EA, the AOT cache contains
AOT klasses and methods, AOT method profiles, AOT Java objects like
interned strings, and AOT nmethods.  All of these things have been
generated in the past mainly on a just-in-time basis.)

Some nmethods have dependencies which are more demanding than the
dependencies on the overall AOT cache.  That is, even if the AOT cache
is ?cleared for takeoff? (matching flags like narrow oops, etc.), an
individual nmethod within its AOT code cache might be impossible to
adopt as the compilation of its method.  In our premain EA this can
happen because an nmethod X demands that some klass Foo be initialized,
and Foo has not yet been initialized; only when Foo is fully initialized
is the nmethod X (in the code cache) a candidate for connecting to
its Java/JVM method.  Also in this case, there is often another nmethod
X0 (also in the AOT code cache) for the same Java/JVM method, which
does NOT require Foo to be initialized; this nmethod is adopted ASAP
during startup, and only gets replaced when Foo (and every other klass
that X ?cares about?) comes to be initialized.

I think if we make other kinds of individual dependencies on AOT nmethods,
such as ?platform must support AVX-512?, we might also think about generating
two versions, one with the demanding dependency, and one without.  A
dependency, if asserted, creates a sort of ?debt? to say what should happen
when the dependency fails (or is not yet true, as in the case of class
initialization).  That ?debt? can be satisfied by having two versions of
some individual AOT cache asset, or of the AOT cache as a whole.

There could possibly be a use case for storing dependencies on other
kinds of assets in the AOT Cache.  For example, suppose a klass K is
somehow optionally loadable.  (Old CDS does just-in-time loading, so
this is physically possible in the AOT cache as well.)  We are
emphasizing AOT loading and linking, in the premain phase, but
perhaps klass K must be loaded ?the old fashioned way? by processing
its pre-parsed representation.  I can imagine there could be some
dependency-like information attached to klass K that says ?do not
adopt this asset unless XYZ is true?, and XYZ is something more
specific than the overall dependencies written into the AOT cache.
But here I am just speculating about something that might be useful
in thefuture.  Again, the current work focuses on profiting from
the decision to load and link as many classes as possible in the
premain phase, the startup moments before application main is invoked.
And all classes loaded in premain phase are loaded as a block, so
they either stand together or fall together, based on whatever
dependencies are written into the AOT cache as a whole.

> I'll for sure have more questions and things to discuss once I start working on this, which I'm planning to do next Monday.
> My first step will be trying to get an overview of all sorts of "flags" that I'll have to add to the record.
>
>
> I'm glad to start working on this!
> Cesar

Thanks!

? John

P.S. I?d like to invite anyone working on ?dependencies? (in the broad
sense) to think about how there might be a ?dependency API? that
applies in multiple places, and perhaps could be encoded (in multiple
places) in ways that are somehow uniform in our C++ code.  Currently,
dependencies.hpp is only for nmethods, since those are the key
optionally useable items in the JVM.

(You can always discard an nmethod, but you can't discard most other
items in the JVM, until the GC gives you permission.  Something which
is optionally discardable is also optionally usable, and can be
coupled to side conditions that are unpredictable.  So an nmethod can
depend on the fact some particular method has no overrides, because it
can be transparently discarded when a new class with an override is
suddenly loaded.  In Leyden, a cached AOT nmethod can also depend on
some granular platform feature like AVX-512 that the rest of the AOT
cache ignores.  The common thread is an optionally adoptable and/or
optionally discardable asset of some sort.)

In the AOT cache, there are potentially many kinds of optionally
adoptable assets, since the JVM in many cases can decide to regenerate
an item it needs from scratch, just in time, rather than adopting a
cached AOT asset. I can?t imagine a dependency on an AOT klass asset
(other than a useless one the duplicates a dependency on the whole AOT
cache) but maybe there is one.  (Note: the term ?klass? is the
JVM-internal name for a metadata object that represents a loaded
classfile.  When I say ?class? I might be referring to many things in
source code or elsewhere, and I don?t always mean ?or interface?.  But
?klass? means ?metadata for a loaded classfile?.  It also sometimes
means metadata for something else like /new int[0].getClass()/.)

OK, here is one very simple dependency, which probably does not need
an individual call-out: Some optionally adoptable klass asset K might
?bake in? stabilized pointers into the block of premain klasses.  In
that case, it would be a mistake to load and link K before Object,
String, and all the premain classes were loaded and linked.  I suppose
if we (in the far future) ever organized multiple blocks of klass
assets in layers the layers themselves could have load-sequence
dependencies.  A layer would be like a shared library that requires
resolved references to previously loaded shared libraries; the OS must
load those previous ones first and then load the shared library that
depends on it.  I say ?far future? because this idea (klass layers) is
the sort of thing that comes up routinely, and is routinely put on the
list of things to examine later.

Maybe there are somehow concepts in dependencies.hpp that could be
teased out for use in other places.  Or perhaps there is no
cross-application, and logical dependencies look completely different
when applied to the AOT cache as a whole, and again applied to
nmethods, and perhaps later applied to some other optionally adoptable
asset within the AOT cache.  Still, it would be nice to have a common
API, especially there is parallel growth of complexity at the level of
nmethods and on the whole cache (e.g., of dependencies on flags).  Or
if there is a third location for dependencies (optional klass assets?)
it might be nice to make a new use of an existing API instead of
building out new dependency logic (in the new place) from scratch.

From john.r.rose at oracle.com  Tue Aug 27 16:55:46 2024
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 27 Aug 2024 09:55:46 -0700
Subject: Encapsulating JVM Options
In-Reply-To: <9DF94F77-5292-40FE-B258-9BA4E3C35E21@oracle.com>
References: <CH2PR21MB151167D4A0854C44EFC98E579A8C2@CH2PR21MB1511.namprd21.prod.outlook.com>
 <1C91B949-D3BA-49DB-A3C0-C2FBDB51BE94@oracle.com>
 <3AA8412F-CB31-4DA0-8105-29979B300480@oracle.com>
 <MN2PR21MB15206C7663A2A91F239D79E19A882@MN2PR21MB1520.namprd21.prod.outlook.com>
 <9DF94F77-5292-40FE-B258-9BA4E3C35E21@oracle.com>
Message-ID: <1CEC07BF-EBC5-461A-B962-ADC4B9C9FCD6@oracle.com>

On 27 Aug 2024, at 9:49, John Rose wrote:

> All of these things have been generated in the past mainly on a just-in-time basis.

Ugh, that was unclear.  I mean to say klasses, nmethods, profiles, Java objects,
etc., are normally generated by the JVM just in time, on demand, in the course
of Java execution.  Adding AOT versions of all these things is the job of the
AOT cache.  Also historically the job of CDS, which generated pre-parsed
versions of String, Object, etc.  So, ?in the past,? a few AOT operations were
managed by CDS, but until the new AOT cache features, everything is ?mainly?
generated JIT, as needed, on demand.

From Divino.Cesar at microsoft.com  Tue Aug 27 17:19:54 2024
From: Divino.Cesar at microsoft.com (Cesar Soares Lucas)
Date: Tue, 27 Aug 2024 17:19:54 +0000
Subject: Some offhand questions
In-Reply-To: <SA1PR10MB58853F8FAEAE325F060D4CF2828B2@SA1PR10MB5885.namprd10.prod.outlook.com>
References: <MN2PR21MB1520FB8265FD2801AD126EBB9A882@MN2PR21MB1520.namprd21.prod.outlook.com>
 <36ff7b53-e898-48b6-952a-7e6ce284ef18@oracle.com>
 <SA1PR10MB58853F8FAEAE325F060D4CF2828B2@SA1PR10MB5885.namprd10.prod.outlook.com>
Message-ID: <SJ1PR21MB364892AEFDED221E3B388C3C9A942@SJ1PR21MB3648.namprd21.prod.outlook.com>

I just inspected the top 10 used artifacts in Maven Central and none of the jars are signed..

I was led to ask this question here because I noticed the warning in the JVM console when trying the EA build on some internal projects. I'll check with our product teams to find the reason why they are shipping signed jars and whether they can drop that.


Thanks
Cesar
________________________________________
From: leyden-dev <leyden-dev-retn at openjdk.org> on behalf of Ioi Lam <ioi.lam at oracle.com>
Sent: Monday, August 26, 2024 2:01 PM
To: Leyden-dev Maillist
Subject: Re: Some offhand questions

Many apps used signed jars "accidentally". When signed jars were fashionable, some lib developers signed their jars. Many of these libraries become orphaned and remain signed for no particular reason.

The reason that CDS doesn't archive signed classes is because we aren't sure if we skip the whole signature checking process at run time, we can still ensure that all APIs related to code signing (eg Class.getSigners) can return the expected value.

Cesar, could you confirm if the class signatures are actually used for something useful?

If not, I think maybe we can introduce a new execution mode, to simply ignore code signatures.

Or drop support for signed jars as Alan mentioned below.

Thanks
Ioi



-----------

 From: leyden-dev <leyden-dev-retn at openjdk.org> on behalf of Alan Bateman <alan.bateman at oracle.com>
Sent: Saturday, August 24, 2024 7:23 AM
To: Cesar Soares Lucas <Divino.Cesar at microsoft.com>; Leyden-dev Maillist <leyden-dev at openjdk.org>
Cc: Brian Stafford <Brian.Stafford at microsoft.com>; Mat Carter <Matthew.Carter at microsoft.com>
Subject: Re: Some offhand questions



On 23/08/2024 23:04, Cesar Soares Lucas wrote:

Hello!

I've a few questions that I'd like to ask your opinion about.

- Signed Jars: As far as I understand, we currently don't include classes from signed jars in the CDS archive. What is the reason for that? I had the impression that being able to archive such classes would be important given that many .jars are signed?!



As a general point, signed JARs on the class path or module path aren't all that useful. It's very different to a signed JAR loaded from a remote site where the JDK would need a lot more infrastructure to validation certificate chains. There has been consideration on and off for many years about dropping the support for JAR files on the class path (and module path). The nice thing about dropping this (only from the class path and module path) is that it would avoid executing a lot of problematic security code when open JAR files.

-Alan



From john.r.rose at oracle.com  Tue Aug 27 17:35:40 2024
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 27 Aug 2024 10:35:40 -0700
Subject: Some offhand questions
In-Reply-To: <MN2PR21MB1520FB8265FD2801AD126EBB9A882@MN2PR21MB1520.namprd21.prod.outlook.com>
References: <MN2PR21MB1520FB8265FD2801AD126EBB9A882@MN2PR21MB1520.namprd21.prod.outlook.com>
Message-ID: <AA4CD986-1377-42E7-A23A-60B477A46285@oracle.com>

On 23 Aug 2024, at 15:04, Cesar Soares Lucas wrote:

> Hello!
>
> I've a few questions that I'd like to ask your opinion about.
>
> - Signed Jars: As far as I understand, we currently don't include classes from signed jars in the CDS archive. What is the reason for that? I had the impression that being able to archive such classes would be important given that many .jars are signed?!

Those were good replies from Alan, Dan, and Ioi?

This is an example (one of many) of a possible work-item which we occasionally
discuss, and then put back onto the priority list, very low down.  In this case
we might escape ever implementing it, unless the feature is somehow found to be
important to users of the AOT cache.  (And, it survives into the future.)

We almost need a shorthand here for ?yes we have discussed that feature,
we expect to re-discuss it occasionally, and we don?t find it to be more
urgent than features already on our full plate?.  Sometimes we file
tracking bugs for such features that are intentionally sidelined.

> - Profile/Archive score: I've been thinking that maybe a profile/archive score would be something useful to have at some point. The goal with such a "score" would be to report back to the user how much information from the archive was effectively used during a production run so that they have some insight about how "good" was the training run used to create the archive. The score for an archive could be an [weighted] aggregate of the scores of specific parts of the archive. We could also use the scores, in the future, if we choose to work on something to "merge" or "combine" multiple archives.

I mentally file ideas like this in ?stuff the JVM should log about?.
There is a low barrier to entry for adding log items.  If such a bit of
information is useful for our end users we should provide a way to log it.

Some users will rapidly come to the place where the size (bulk, footprint)
of their AOT cache will push against limited resources (disk, bandwidth).
We need to be ready to help them ?throttle back? the creation of AOT
resources.  This is one reason we periodically discuss ways to filter
the assets in the AOT cache.  We?ll need a story for this eventually,
though not immediately.  We also need a way, as you say, to evaluate
the result of a certain set of filter options.  For our own heuristics,
which determine ?vanilla? behavior of the AOT cache, we also need the
similar evaluation of effectiveness.

One way to think about this is to give uniform names to AOT cache
assets, and use those names in two places in log output.  First,
when the asset is created (or when a hypothetical ?dump command?
is executed), mention the asset.  (By asset I mean any AOT item:
klass, method, profile, nmethod, object, etc.)  Second, when the
asset is used, mention it again, and perhaps the circumstances of
its use.  A simple tool could then compare the list of created
assets against the list of used assets.  For klasses which are
loaded in bulk during premain, maybe that second report is not
interesting, but it might (again) be interesting to look at the
logged list of which classes were initialized, or maybe those
which were instantiated.  There?s lots of ?in principle? work
here we could do, which might detour us into wasted effort,
so probably such logging work should be done in the setting
of problems we know users will eventually have, such as over-sized
AOT code caches.  That means we should work on code caching first,
then work on managing/curating/filtering/sizing the AOT code cache.

> - Condensers: I've been asked recently about the idea of condensers. As far as I understand there is nothing implemented on the lines of that idea. Is this something that we still plan to work in the future?

Given the ?unreasonable effectiveness? of our current work, as Dan puts
it, we have placed such ideas low on the priority list.  Very low indeed.

Picking up on a theme Dan mentioned, I would like to work on bootstrapping
our indy/condy/MH/VMAC/LF initialization activities within premain, and not
as a separate tranche of engineering work.  This means making another look
at how java.lang.invoke APIs are wound up in Java application startup, and
finding ways to ensure that training runs ?fill up the AOT cache? with useful
assets.  I don?t think anyone has looked at refactoring those initialization
activities, in the setting of premain, other than some work Vladimir Ivanov
did.  More work on indy/condy/MH/VMAC/LF initialization activities which
cooperate with premain (and especially pre-linking and cache filling
functions of premain) would bear more fruit, I think.

Such work might also reduce pressure on javac to provide special hacks
to avoid bootstrap problems in ?the first 100 classes? of java.base.
IIRC we disable the indy-based string concat logic, when building
java.base, because there are too many bootstrap cycles.  I think a
premain-oriented approach to indy bootstrapping might possibly relieve
javac (and our makefiles) from pulling this trick.  The approach I
have in mind is to satisfy indy/condy/MH/VMAC/LF requests during
the earliest bootstrap phases (the ?first 100?) by means of some
slow path that aligns well with the premain assembly phase.  That
is, arrange for the ?first 1000? indy/condy/MH/VMAC/LF requests
to be fulfilled from a boot cache which is normally filled by
premain logic, and which can also be filled (in some unspecified
painful way) if the AOT cache is not present.  The unspecified
painful way might be a hand-curated set of pregenerated classes,
similar to work in the past on LFs.  These bootstrap-only paths
for handling that stuff would be code in java.base, not special
modes in javac, so they could be managed and minimized more directly.

(OTOH, some folks have said they like the simplicity of giving
javac a special output mode for java.base.  I?m not sure that will
scale given the many new indy-based language features arising.
As someone who works more on libraries than javac, my hammer
of choice is modification to library code, of course.)

> - Recompilation: I've been reviewing the changes in the @premain branch, and I came across this piece of code [1] and was puzzled by it. Why do we recompile the code at every compilation level? There is a lot I still don't understand about the implementation in premain, but what I was expecting was that at some point in the code we would just "dump" the code cache and that would be our "AOT compiled code".

That was our understanding at first.  It might seem that ?all you need
to do? is snapshot the JVM?s JIT code cache at ?the end of time? (after
training) and reuse it all at ?the beginning of time? in the production run.

In reality, the premain training run emits (mostly) symbolic steering
information which causes the assembly phase to perform fresh compilations
of AOT methods.  And some of those AOT methods have to accommodate special
conditions at the ?beginning of time? (such as not-yet-initialized classes).

If the application has a long self-configuration phase, the ?end of time?
methods might actually deoptimize due to transient execution patterns
(eventually obsolete hot-spots); there might be a ?middle of time? in
a large application which we need to cover somehow.  This is why there
is always an option to so online (JIT) compilation even when AOT methods
are available.  Also, if we have a very good ?end of time? AOT method,
and it deoptimizes, the replacement policy should take into account
that there is evidence that it will eventually be useful.  So although
we tend to immediately dump JIT methods when they show the first sign
of unexpected behavior, AOT methods should be kept around longer.
And as such, they may have subtly different management of their own
internal fastpath/slowpath organization, compared to JIT methods.

Igor could tell you more?

> Thanks,
> Cesar
>
> [1] https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/compiler/precompiler.cpp#L234

From duke at openjdk.org  Wed Aug 28 15:35:49 2024
From: duke at openjdk.org (duke)
Date: Wed, 28 Aug 2024 15:35:49 GMT
Subject: git: openjdk/leyden: premain: Fix various build configs for clean PRs
 and happy CIs
Message-ID: <b53a64df-4883-42ac-b26d-19c12451d3db@openjdk.org>

Changeset: b96c5113
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: iklam <ilam3388 at gmail.com>
Date:      2024-08-28 07:37:28 +0000
URL:       https://git.openjdk.org/leyden/commit/b96c511323aea6ffb2fc972817c779b4bacaf9fa

Fix various build configs for clean PRs and happy CIs

! src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp
! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
! src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
! src/hotspot/cpu/s390/templateInterpreterGenerator_s390.cpp
! src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp
! src/hotspot/share/cds/archiveBuilder.hpp
! src/hotspot/share/cds/cdsConfig.cpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/interpreter/bytecodeHistogram.cpp
! src/hotspot/share/interpreter/bytecodeTracer.cpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/memory/virtualspace.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/recompilationSchedule.cpp
! src/hotspot/share/oops/trainingData.cpp
! src/hotspot/share/oops/trainingData.hpp
! src/hotspot/share/opto/runtime.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/methodHandles.cpp
! src/hotspot/share/prims/methodHandles.hpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/perfData.hpp
! src/hotspot/share/runtime/perfData.inline.hpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/threads.cpp
! src/hotspot/share/runtime/vmThread.cpp


From john.r.rose at oracle.com  Wed Aug 28 19:02:20 2024
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 28 Aug 2024 12:02:20 -0700
Subject: EA feedback
In-Reply-To: <DS0PR10MB627145CC00B9318C3B728697E7882@DS0PR10MB6271.namprd10.prod.outlook.com>
References: <CAABjz10oAmoLkEfLSLo0MN7+BzCFQJ5VYSkmhWH6GB6SVrF57Q@mail.gmail.com>
 <CAKt0pySHtZHSk0FyarM7kkdygTBppHBcYfpXPOfiJuS+7qjQyg@mail.gmail.com>
 <bcf26ac8-663f-4b11-abb3-1ca942d506e2@oracle.com>
 <A0C193BF-B8DB-4BC6-95D5-BBA21DC92F27@oracle.com>
 <BL4PR21MB41283FFEC5120462CF5129368A8F2@BL4PR21MB4128.namprd21.prod.outlook.com>
 <DS0PR10MB627145CC00B9318C3B728697E7882@DS0PR10MB6271.namprd10.prod.outlook.com>
Message-ID: <EA018C7F-9B39-4AC0-81CC-FAA2367D8C9D@oracle.com>

Thanks Dan; I agree.  In the Leyden premain engineering group, it is 
very
common for folks to confront a hard problem (like training run 
specification)
by making long lists of possible solutions. I like our habit of 
acknowledging
those long lists, noting them down somewhere (perhaps in a filed RFE) 
and then
selecting the top one or two items to do, ruthlessly discarding the 
rest.
That?s the way we have made progress, and have avoided ?more is 
merrier?,
or ?design by committee?, which for us would be a trap.

How do we select the top one or two?  By picking one which will be the 
simplest
to implement, and serve 80-90% of the use cases.  For bonus points we 
can try to
identify the most effective primitive the underlies the myriad of 
proposed
surface features, and steer our engineering in that direction.  That?s 
what
I way trying to do in pointing out a ?breakpoint like? mechanism 
that might
be the JVM primitive to build ? the eventual primitive, if not the 
first
thing we build.

I will also say that any ?training run API? to be invoked by the 
training
run is probably very low down on the list of priorities, even if it is
everybody?s first thought of how to run things.  
(System::trainingIsDone,
amiright?)  First, that requires modifications to application code, 
which
only a minority of users will welcome (so it?s not an 80% solution).
Second, the design of such an API is very subtle, and we don?t have
enough experience with the primitives or the workflows to propose a
good API.  Therefore, if such an API arises, it will be years in the
future, after we have covered many other use cases, and after we
understand how best to shape such an API.  As I noted elsewhere,
if we have a flexible ?breakpoint-like? primitive for triggering
training run dumps, any user can build their own trainingIsDone
method on top, if they really want it.

On 23 Aug 2024, at 6:53, Dan Heidinga wrote:

> For some background on my thinking here:  There are two extremes here 
> I?d like to avoid ? the first is ?clean exit is the only way to 
> stop training?, and the second is the ?the more the merrier? 
> configuration extreme.  I think we?re already moving away from the 
> first (good!) but I don?t want us to move so far away we run into 
> the second.  I have a lot of OpenJ9 experience which had two great 
> tools for hooking into system events ? the dump and trace apis.  
> Unfortunately, they both had grown all manner of bells and whistles 
> that required webapps to generate the required set of options.  Great 
> tool ? terrible UX.  All that to say I?m somewhat hesitant of 
> being too configurable.
>
>
>
>  My preference is to build the minimum hooks into the runtime that 
> allow *external* processes to trigger the end of training.  John?s 
> proposal to use a breakpoint-like mechanism spells out the runtime 
> internals of one such mechanism to support an external process (config 
> file, command line, api  or jcmd) triggering the ?end-training? 
> signal.
>
>
>
>  Can we spin the two new requests as being part of such an external 
> process?  Are they more naturally VM primitives?
>
>
>
>  --Dan
>
>
>
>  From:leyden-dev <leyden-dev-retn at openjdk.org> on behalf of Mat Carter 
> <Matthew.Carter at microsoft.com>
>  Date: Thursday, August 22, 2024 at 12:04?PM
>  To: John Rose <john.r.rose at oracle.com>, Ioi Lam <ioi.lam at oracle.com>
>  Cc: leyden-dev at openjdk.org <leyden-dev at openjdk.org>
>  Subject: Re: EA feedback
>
>  Having considered the JBS issue [1], we'd like to propose/discuss 
> some additional options, the thought being that while implementation 
> can be staggered it might be helpful to consider them now to help 
> prioritize/rethink/reject.
>
>
>
>  In summary we currently have the "stop" action, stopping is immediate 
> (now) and operationalized via the following mechanisms:
>
> ??????? Ctrl-Z/D
>
> ??????? System.Exit()
>
> ??????? Run to completion (normal termination)
>
> ??????? Unhandled exception :)
>
>
>
>  And this new ask in JBS [1] is to
>
> ??????? Add a mechanism using 'jcmd' and/or a new Leyden 
> API to action the existing "stop" (now) functionality
>
> ??????? Add a variant of the "stop" action where 
> training stops when execution enters a java method (optionally after N 
> invocations); specify method to stop on via Command Line (-XX), JCmd 
> and/or Leyden API
>
>
>
>  We?d like to propose two additional variants to aid with stopping 
> training runs:
>
> ??????? Stop training after some time has elapsed
>
> ??????? Stop training when some threshold is met
>
>
>
>  The second point comes from considering the definition of 'startup 
> complete' and 'warmup complete'.  Considering the developer is already 
> engaged in AOT training, we should allow the developer to aid the 
> training by:
>
> ??????? Indicating when the application has completed 
> startup (ready to work)
>
> ??????? Indicate when the application has completed 
> warmup, either by:
>
> ????????????? Calling an API to indicate 
> warmup is done
>
> ????????????? Calling an API when a chunk of 
> work has completed, passing in the 'duration'; this 'duration' is 
> compared to some specified 'threshold' to generate the 'warmup is 
> complete' event
>
>
>
>  Adding a threshold means that training runs can be of optimal length 
> and can handle changes in the environment and/or code.  Coupled with 
> maybe an "abort training" action we now have a training run that 
> targets a threshold and aborts if not reached in time N.
>
>
>
>  Currently we have the command line, jcmd and a new Leyden API to 
> support training runs.  Lastly we'd like to propose a fourth method 
> that being an MxBean (uses the new Leyden API); this would allow the 
> developer to provide the startup and warmup indicators internally or 
> externally (their choice), and would allow for runtime analysis using 
> bespoke production systems or JMC, and offline analysis via JFR.
>
>
>
>  Cheers
>
>  Mat
>
>
>
>  [1] https://bugs.openjdk.org/browse/JDK-8335358
>
>
>
>  From:leyden-dev <leyden-dev-retn at openjdk.org> on behalf of John Rose 
> <john.r.rose at oracle.com>
>  Date: Friday, August 16, 2024 at 4:51 PM
>  To: ioi.lam at oracle.com <ioi.lam at oracle.com>
>  Cc: leyden-dev at openjdk.org <leyden-dev at openjdk.org>
>  Subject: Re: EA feedback
>
>  Here?s the way I would prefer to think about a ?dump command?.
>
>  The native way that the JVM represents sequential operations is
>  the method. Talking about methods is therefore a basic way to
>  specify a condition for injecting a JVM operation like training
>  dumps. I would like to figure out a good way to tie the training
>  dump to the invocation of a method, either a single well-known
>  method, or to a method specified (on the command line) by the
>  user.
>
>  In fact, it feels like a breakpoint-like operation would be a
>  natural way to view the training dump. You don?t need JVMTI
>  to get it done; you just need a hack in the VM which parallels
>  the existing breakpoint mechanism, but special-cases it to
>  drive a training dump.
>
>  Given such a foundation, jsig could then inject a call to a
>  method which is appropriately tied to the dump command.
>
>  Sketch of implementation:
>
>  When a method is first linked, a list is checked to see if
>  it has a dump event tied to it, and a bit is set on the method.
>  The method?s interpreter entry point might be modified, or
>  perhaps the interpreter just always checks the bit. On entry
>  to the method, before the first bytecode, an upcall tells
>  the VM that it?s time to finish the training run.
>
>  The compilers also check this bit, of course.
>
>  There is some method deep in the privates of java.base
>  that is always treated this way. That?s what jcmd reaches.
>  There is a command line option which lists more methods
>  to treat this way, something like the CompileOnly command.
>
>  As a separate option, the upcall to end the training run
>  might return (allowing the VM to continue) or just exit.
>
>  As a separate option, allow the user to specify a count N,
>  so that the training dump happens only after N ?hits? on
>  any marked method(s).
>
>  I think all this is useful and flexible.
>
>  On 13 Aug 2024, at 18:22, ioi.lam at oracle.com wrote:
>
>>
>>
>> On 8/13/24 12:42 PM, Ashutosh Mehra wrote:
>>
>>>> Being able to trigger assembly/verification via jcmd without 
>>>> exiting, would make this far easier for us to support.
>>>
>>>
>>>
>>> There is a proposed enhancement for doing exactly this (and 
>>> exploring other ways to trigger end of training run); see 
>>> https://bugs.openjdk.org/browse/JDK-8335358
>>
>>
>>
>> I am working on a prototype for dumping with jcmd. It will be similar 
>> to the existing "jcmd VM.cds statoc_dump" command, except that it 
>> will also support the dumping of the AOT cache and profile data.
>>
>>
>>
>> Thanks
>>
>> - Ioi
>>
>>
>>
>>>
>>>
>>> Thanks,
>>>
>>> - Ashutosh Mehra
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Aug 9, 2024 at 4:38?PM Danny Thomas <dannyt at netflix.com> 
>>> wrote:
>>>
>>>> I tried 24-leydenpremain+2-8 on a few internal applications, some 
>>>> quick feedback below (good to see you folks at the JVM LS!).
>
>>>> If a jar has a Class-Path attribute and one or more of those 
>>>> libraries are explicitly on the classpath, it causes the actual and 
>>>> expected classpath to always differ. This is also the case 
>>>> currently with CDS of course, but this feature is sure to be 
>>>> deployed far more broadly than CDS is currently, so likely 
>>>> something you want to look at:
>
>>>> [0.057s][info][class,path] non-existent Class-Path entry 
>>>> lib/failureaccess-1.0.1.jar
>>>> [0.057s][info][class,path] opened: 
>>>> lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
>>>> [0.057s][info][class,path] library = 
>>>> lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
>>>>
>>>> Startup time when training seems to be on par with 
>>>> ArchiveClassesAtExit in JDK 21, but it's about a 3.5x startup time 
>>>> penalty for one of our typical Spring Boot applications. From a 
>>>> back-to-back run on my machine (AMD EPYC 9R14, 32 cores, 123G, 
>>>> Ubuntu 22.04.4 LTS):
>>>>
>>>> Started App in 7.698 seconds (process running for 8.229)
>>>> Started App in 26.247 seconds (process running for 29.262) - w/ 
>>>> CacheDataStore, Training Run
>>>> Started App in 4.341 seconds (process running for 4.917)  - w/ 
>>>> CacheDataStore, Production Run
>
>>>> I also got a crash on one attempt, I can't remember what I did to 
>>>> cause this unfortunately:
>
>>>> Stack: [0x00007f3949ab0000,0x00007f3949bb0000],  
>>>> sp=0x00007f3949bae628,  free space=1017k
>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
>>>> C=native code)
>>>> V  [libjvm.so+0x42ca30]  ArchiveBuilder::get_buffered_addr(unsigned 
>>>> char*) const+0x40
>>>> V  [libjvm.so+0xce4aa5]  VM_PopulateDumpSharedSpace::doit()+0x395
>>>> V  [libjvm.so+0x100ae69]  VM_Operation::evaluate()+0x109
>>>> V  [libjvm.so+0x100e348]  
>>>> VMThread::evaluate_operation(VM_Operation*)+0xe8
>>>> V  [libjvm.so+0x10142fb]  
>>>> VMThread::inner_execute(VM_Operation*)+0x35b
>>>> V  [libjvm.so+0x101460f]  VMThread::run()+0x16f
>>>> V  [libjvm.so+0xf6e5cf]  Thread::call_run()+0x9f
>>>> V  [libjvm.so+0xd74e13]  thread_native_entry(Thread*)+0x183
>>>> C  [libc.so.6+0x98b07]
>
>>>> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 
>>>> 0x0000000000000030
>>>>
>>>> Thinking ahead to operationalizing AOT, while a single-shot/on-exit 
>>>> workflow is great for iterating locally, requiring the VM to exit 
>>>> makes this more difficult to operationalize at scale:
>>>>
>>>> 1.   We'll perform training and assembly on test, production canary 
>>>> and production instances on behalf of application owners and handle 
>>>> distribution of the archives. Depending on when we're able to 
>>>> perform a training run, it'll have different benefits. i.e.:
>>>>
>>>> 1.   Test environment will at least improve startup performance, 
>>>> with a mixed benefit for warm up depending on the kind of traffic 
>>>> they take in test
>>>>
>>>> 2.   If an application uses canary deployments we'll have a full 
>>>> production profile prior to the full production deployment, and all 
>>>> instances will come up hot
>>>>
>>>> 3.   If we reach production with only a test environment profile, 
>>>> we'll perform a training run in production, so instances that scale 
>>>> up following that run will come up hot (completely cold instances 
>>>> for an initial deployment is less of a concern, because we deploy 
>>>> immutably and get a natural warm-up period while we have 200% 
>>>> capacity online for a cluster)
>>>>
>>>> 2.   It's currently not a problem if a VM doesn't exit completely 
>>>> due to a dangling non-daemon thread or hung shutdown hook
>>>>
>>>> Being able to trigger assembly/verification via jcmd without 
>>>> exiting, would make this far easier for us to support. If the 
>>>> overhead of the instrumentation for CDS can be avoided, being able 
>>>> to take a snapshot at any time on any VM would be better still, but 
>>>> that wouldn't be an impediment for us: we'll know that the instance 
>>>> will be used for training at boot time.
>
>>>> We build nightlies of all the currently active OpenJDK projects, so 
>>>> if you land anything on premain between EA builds that you'd like 
>>>> us to try, let us know!
>
>>>> Cheers,
>>>> Danny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240828/b00af02a/attachment.htm>

From duke at openjdk.org  Wed Aug 28 21:21:32 2024
From: duke at openjdk.org (duke)
Date: Wed, 28 Aug 2024 21:21:32 GMT
Subject: git: openjdk/leyden: premain: 2 new changesets
Message-ID: <9dc87928-50a2-4745-a0a5-fe3095b0e3e5@openjdk.org>

Changeset: 1bd62091
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-26 21:32:09 +0000
URL:       https://git.openjdk.org/leyden/commit/1bd6209119e17dcd17c294b8b3441224ad231032

Simplified the archiving of enum class mirrors

! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/cdsEnumKlass.cpp
! src/hotspot/share/cds/cdsEnumKlass.hpp
! src/hotspot/share/cds/classPreinitializer.cpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/heapShared.hpp
! src/hotspot/share/runtime/threads.cpp
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchiveHeapTestClass.java

Changeset: 3a84df9d
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-27 22:44:57 +0000
URL:       https://git.openjdk.org/leyden/commit/3a84df9d9860e743684e335282e3910b14cc982b

Renamed classPreinitializer.cpp to aotClassInitializer.cpp; more heapShared.cpp clean up

+ src/hotspot/share/cds/aotClassInitializer.cpp
= src/hotspot/share/cds/aotClassInitializer.hpp
! src/hotspot/share/cds/cdsConfig.hpp
! src/hotspot/share/cds/cdsHeapVerifier.cpp
- src/hotspot/share/cds/classPreinitializer.cpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/heapShared.hpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchiveHeapTestClass.java


From john.r.rose at oracle.com  Wed Aug 28 22:26:55 2024
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 28 Aug 2024 15:26:55 -0700
Subject: for the record: heat based sorting, driven by training runs
Message-ID: <2842BA99-2D52-4803-8F94-4A10B9FC99D4@oracle.com>

The following thoughts are ?for the record? not ?for
immediate implementation?.  They are an example of good
ideas that come up in our conversations, are given some
thought, and are then prioritized down the list.  For later.
Maybe even for never.  The important thing is to have a
reasonably complete record, so we don?t have to rediscover
and rediscuss such points.  There are ever so very many
of such points, we would be at it forever rediscovering
and rediscussing.

With that said?

It is well known that some workloads (in many languages)
sometimes benefit from changing the order of fields in
structs (or objects or whatever they are called in whatever
language).  In simple terms, if X.A is accessed very often,
and X.Z is accessed seldom, then there is little or no
penalty to putting them on opposite ends of a struct
layout, even though the struct might lie across a data
cache boundary, so that X.A and X.Z must incur distinct
data cache fill events.

The same point is true if the struct is used heavily in
two different ways (different program phases), so that
X.Z is sometimes accessed frequently, but never near the
time when X.A was accessed frequently.

A similar point holds if X.A and X.B are always accessed
together.  You don?t want them to be far away from each
other, far enough to make it likely that they end up on
distinct cache lines (requiring double the number of
fill events for a use of both).

For Java, the object header is, for some classes, accessed
very frequently indeed.  And for others it is almost never
accessed, except during creation and GC!  It depends on
whether the class in question is used solely as a static
type.  There are plenty of examples; the internal nodes
of hash tables work that way.  In any case, the header
works like just another field X.H, in this analysis,
and may be accessed seldom or frequently, and coupled
with other fields, or independently.

There is a distinct NP-hard feel about the optimization
problems here, and yet very simple tactics can lead to
solid benefits (often in the single digit percentage
range).  Sorting fields by frequency of access is well
known.  It covers the case where X.A and X.B are heavily
used together.  It doesn?t cover the case where both are
heavily used but at different times.  That doesn?t matter;
it covers enough cases to be beneficial as a standard
move.

A similar standard move is sorting functions in a code
heap by hotness.  You don?t necessarily have to look at
their caller/callee interrelationships, although that?s
a next step.  And a third similar standard move is to
sort the basic blocks within a function, again by hotness.
For that one, you need to respect their intrinsic in/out
relations, from the start.  What I say about struct layout
can be cross-applied to these other problem areas as well.
Let?s just call all of them ?heat based sorting?, whether
or not the heat is the primary sort key or whether it is
a ?secondary? influence on the resulting order.

A good practical study of how heat-based sorting can help is
here: https://dl.acm.org/doi/abs/10.1109/CGO51591.2021.9370314
This is the Facebook HipHop VM, not a JVM.  But some of their
experiences are relevant to us.

For object layout, the need for holes to get word alignment
will make a pure heat-based sort impractical, but a simple
heat-based sorting pass, followed by some hole-filling that
violates the heat-based order, might work out fine.

The object header should probably go next to the hottest
field, in most cases.  But in cases where the object header
is cold, the object layout could start with cold fields.

In order to make this work, the training run would have to
gather heat statistics.  I imagine a per-class array of
counters, indexed by offset (byte offset) within the class?s
current object layout.  Reading or writing a field (or the
header) increments the counter.  (Extra points for probabilistic
or indirect counters which don?t drive the memory fabric insane,
making the application dynamics non-representative of real,
non-instrumented deployments.  Heisenberg and all that.)

The assembly phase will then take stock of the training run
outputs and re-load everything into a nicely curated bundle
for the production runs.  As it reloads classes, it evaluates
whether their layouts should change (because of interesting
observed dynamics).  Not all should change, but some might,
if they have enough variance across their field statistics.

At that point it is a ?mere matter of programming? to set
up the adjusted (heat-based) layouts.  The Valhalla project
is adding extra ?programmability? to layout logic, so perhaps
we will have some new tools from them.  (Thanks, Fredric.)

A similar point goes for function ordering in the code cache,
on that day (when it comes) when the assembly phase gets
fine-grained control of function placement in the code cache.

Just as alignment considerations require us to modify a pure
heat-based sorting principle, it may be better to put related
functions (of approximately similar heat) back-to-back, even
if the pure heat-based sorting would shuffle together unrelated
functions.

A similar point goes for basic-block sorting, again with caveats
about putting sequential blocks in sequence, unless there is
evidence that sequence has no benefit (because of large variance
in heat).  In the case of basic-block sorting, we have a sticky
problem (noted by the HipHop people) that regeneration of code
will probably obliterate basic block identities.  In order to
reorder basic blocks (in the output phase, for example, which
is where C2 chooses order), the ordering heuristics need to
access profile data for a previous occurrence (in a previous
run) of that SAME block.  We don?t currently have a block
?sameness? criterion.  HipHop does this by having a very
low level BB-based IR, from which they assemble twice,
once with profile counters, and once USING those counters.
We could do this (perhaps with deep C2 cuts) or we could
contrive to ?name? our basic blocks in such a way that
they OFTEN (perhaps not always) correspond to IR generation
tasks that work from a common source (classfile, inline
tree) but do not necessarily create exactly the same set
of basic blocks.  That might be enough, depending the
?naming scheme? we come up with to refer to basic
blocks as they are generated (during training for
profiling) and later on a second time (during assembly).
I don?t have a clear solution to propose yet, but that
is the way I see this particular problem space.

Although it is not urgent yet, at some point somebody
(maybe a graduate student?) might wish to try out a targeted
experiment with field reordering, and see what pops out.
We don?t have time to depend on this now, and we have enough
high-priority (cheaper and more rewarding) tasks to fill our
plate.  But, these are my thoughts for the record?

? John

From john.r.rose at oracle.com  Wed Aug 28 22:31:38 2024
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 28 Aug 2024 15:31:38 -0700
Subject: for the record: heat based sorting, driven by training runs
In-Reply-To: <2842BA99-2D52-4803-8F94-4A10B9FC99D4@oracle.com>
References: <2842BA99-2D52-4803-8F94-4A10B9FC99D4@oracle.com>
Message-ID: <266D9874-3F23-49A9-818E-79C6BD2BA71A@oracle.com>

P.S. Also FTR, I sent a related set of ideas to Lilliput.  The point
there is that the dynamics of certain PARTS of object headers can be
predicted by training run profiles, and there may be possible uses for
such profiles.  Those are far more speculative than the ideas of
field, method, and BB ordering.

for the record: header bit dynamics could possibly change after Leyden training runs
https://mail.openjdk.org/pipermail/lilliput-dev/2024-August/001819.html



From ioi.lam at oracle.com  Thu Aug 29 04:26:31 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Wed, 28 Aug 2024 21:26:31 -0700
Subject: RFR: 8338017: Add AOT command-line flag aliases (Leyden)
Message-ID: <47d6d5ea-fd68-4b12-91f8-fef40e3cf58a@oracle.com>

Hi Leyden developers,

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

Please review the first PR for JEP 483: Ahead-of-Time Class Loading & 
Linking [1].

JEP 483 is still in the Candidate stage, but I would like to get the 
reviews rolling so we can integrate soon after it's targeted.

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

Thanks

- Ioi

===

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


From duke at openjdk.org  Thu Aug 29 16:35:11 2024
From: duke at openjdk.org (duke)
Date: Thu, 29 Aug 2024 16:35:11 GMT
Subject: git: openjdk/leyden: premain: Simplified dumping of MethodType with
 the AOTHolder pattern
Message-ID: <ad01620c-6456-4077-b4f1-3ab217521376@openjdk.org>

Changeset: e33ecb3e
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-28 18:04:19 +0000
URL:       https://git.openjdk.org/leyden/commit/e33ecb3ec42d142569227b4bd1987124e5551cde

Simplified dumping of MethodType with the AOTHolder pattern

! src/hotspot/share/cds/aotClassInitializer.cpp
! src/hotspot/share/cds/heapShared.cpp
! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/LambdaForm.java
! src/java.base/share/classes/java/lang/invoke/MethodType.java
! test/hotspot/jtreg/TEST.groups


From ioi.lam at oracle.com  Thu Aug 29 17:10:32 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Thu, 29 Aug 2024 10:10:32 -0700
Subject: AOTHolder pattern for caching heap objects
Message-ID: <8394149d-6ec1-4b52-a454-14d40dbf8223@oracle.com>

For the development of JDK-8293336 [1], I am experimenting with a 
pattern of Java code to indicate what heap objects should be stored in 
the AOT cache. This code has been pushed to the premain branch.

It looks like this [2]:

class java.lang.invoke.MethodType {

 ??? static class AOTHolder {
 ??????? private static final @Stable MethodType[] objectOnlyTypes = new 
MethodType[20];
 ??????? private static @Stable HashMap<MethodType,MethodType> 
archivedMethodTypes;
 ??? }

Essentially the class MethodType$AOTHolder will be stored in its 
"already initialized" state in the AOT cache. In the production run, 
MethodType$AOTHolder.<clinit> will NOT be run. Its static fields are 
already initialized and point to the objects that were created during 
the assembly phase.

Currently, the JVM is hard-wired to recognize only a few known AOTHolder 
classes. This pattern is used strictly for the AOT-caching of 
MethodType.internTable.

I want to hear people's reaction to this. I think other internal JDK 
classes can use a similar pattern as well.

(In the long term, we will need a more generalized way (a.k.a. the 
"Scrambled Egg API"), but I need to have a mechanism that works for the 
short term).

***

The reason I needed to use the AOTHolder pattern is to remove this 
horrible hack [3]. (It's now removed from the premain branch). You can 
see more info in the comments of [3], but the gist is:

- The old way of CDS heap object caching depends on re-executing the 
<clinit> methods of classes that want to cache heap objects

- These classes would call CDS.initializeFromArchive() to fetch the 
cached objects.

- Before CDS.initializeFromArchive() returns the objects, it wants to 
initialize all the classes of these objects (or else the caller would 
end up with an object whose class is not yet initialized)

- This scheme breaks down when several classes want to cache heap 
objects, and their <clinit> intertwine with each other.

The old code in [3] tries to work around a NullPointerException that 
happens due to the intertwining. That is certainly not a sustainable 
approach.

***

The AOTHolder pattern tries to accomplish two things

- Clearly identify what objects should be AOT-cached. In the case of 
MethodType.java, I moved only two of its many fields into its AOTHolder 
inner class.

- Cache the static fields in all the AOTHolder classes as a single 
snapshot. Avoid the need to run <clinit> so we don't need to worry about 
execution order, etc.

======

[1] https://bugs.openjdk.org/browse/JDK-8293336

[2] 
https://github.com/openjdk/leyden/blob/e33ecb3ec42d142569227b4bd1987124e5551cde/src/java.base/share/classes/java/lang/invoke/MethodType.java#L438-L441

[3] 
https://github.com/openjdk/leyden/blob/3a84df9d9860e743684e335282e3910b14cc982b/src/hotspot/share/cds/heapShared.cpp#L1415-L1466


From claes.redestad at oracle.com  Thu Aug 29 17:39:59 2024
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 29 Aug 2024 17:39:59 +0000
Subject: AOTHolder pattern for caching heap objects
In-Reply-To: <8394149d-6ec1-4b52-a454-14d40dbf8223@oracle.com>
References: <8394149d-6ec1-4b52-a454-14d40dbf8223@oracle.com>
Message-ID: <AF9C5EC9-4CA7-444B-8D0D-540F3132AA93@oracle.com>

Hi, 

I think everyone will be happy to see CDS.initializeFromArchive go! 

Some random thoughts:
- Rather than hardcoding on AOTHolder should we put some internal marker annotation to signal intent? E.g @Archivable
- I wonder if this initialization indirection could be generalized using StableValues[1] - along with a marker annotation. That would feel very streamlined and avoid the need for most Holder classes (which is a design center of SVs).

/Claes


> 29 aug. 2024 kl. 19:10 skrev ioi.lam at oracle.com:
> 
> For the development of JDK-8293336 [1], I am experimenting with a pattern of Java code to indicate what heap objects should be stored in the AOT cache. This code has been pushed to the premain branch.
> 
> It looks like this [2]:
> 
> class java.lang.invoke.MethodType {
> 
>     static class AOTHolder {
>         private static final @Stable MethodType[] objectOnlyTypes = new MethodType[20];
>         private static @Stable HashMap<MethodType,MethodType> archivedMethodTypes;
>     }
> 
> Essentially the class MethodType$AOTHolder will be stored in its "already initialized" state in the AOT cache. In the production run, MethodType$AOTHolder.<clinit> will NOT be run. Its static fields are already initialized and point to the objects that were created during the assembly phase.
> 
> Currently, the JVM is hard-wired to recognize only a few known AOTHolder classes. This pattern is used strictly for the AOT-caching of MethodType.internTable.
> 
> I want to hear people's reaction to this. I think other internal JDK classes can use a similar pattern as well.
> 
> (In the long term, we will need a more generalized way (a.k.a. the "Scrambled Egg API"), but I need to have a mechanism that works for the short term).
> 
> ***
> 
> The reason I needed to use the AOTHolder pattern is to remove this horrible hack [3]. (It's now removed from the premain branch). You can see more info in the comments of [3], but the gist is:
> 
> - The old way of CDS heap object caching depends on re-executing the <clinit> methods of classes that want to cache heap objects
> 
> - These classes would call CDS.initializeFromArchive() to fetch the cached objects.
> 
> - Before CDS.initializeFromArchive() returns the objects, it wants to initialize all the classes of these objects (or else the caller would end up with an object whose class is not yet initialized)
> 
> - This scheme breaks down when several classes want to cache heap objects, and their <clinit> intertwine with each other.
> 
> The old code in [3] tries to work around a NullPointerException that happens due to the intertwining. That is certainly not a sustainable approach.
> 
> ***
> 
> The AOTHolder pattern tries to accomplish two things
> 
> - Clearly identify what objects should be AOT-cached. In the case of MethodType.java, I moved only two of its many fields into its AOTHolder inner class.
> 
> - Cache the static fields in all the AOTHolder classes as a single snapshot. Avoid the need to run <clinit> so we don't need to worry about execution order, etc.
> 
> ======
> 
> [1] https://bugs.openjdk.org/browse/JDK-8293336
> 
> [2] https://github.com/openjdk/leyden/blob/e33ecb3ec42d142569227b4bd1987124e5551cde/src/java.base/share/classes/java/lang/invoke/MethodType.java#L438-L441
> 
> [3] https://github.com/openjdk/leyden/blob/3a84df9d9860e743684e335282e3910b14cc982b/src/hotspot/share/cds/heapShared.cpp#L1415-L1466
> 


From duke at openjdk.org  Thu Aug 29 23:34:07 2024
From: duke at openjdk.org (duke)
Date: Thu, 29 Aug 2024 23:34:07 GMT
Subject: git: openjdk/leyden: hermetic-java-runtime: 33 new changesets
Message-ID: <84c0016c-7a36-4960-9f65-ed5ba568ac87@openjdk.org>

Changeset: 8e88da05
Branch: hermetic-java-runtime
Author:    Tejesh R <tr at openjdk.org>
Date:      2024-08-28 04:43:10 +0000
URL:       https://git.openjdk.org/leyden/commit/8e88da05b9966892e117b779d59a2e311a557a8d

8338041: Keyboard Navigation of JTable, Ctrl Shift RIGHT/LEFT doesn't follow native action in GTK L&F

Reviewed-by: honkar, prr, abhiscxk

! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java
+ test/jdk/javax/swing/plaf/gtk/JTableCtrlShiftRightLeftKeyTest.java

Changeset: 2e174c63
Branch: hermetic-java-runtime
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-08-28 09:29:18 +0000
URL:       https://git.openjdk.org/leyden/commit/2e174c6367c7755d8541f9669f7f10ed89878f58

8338445: jdk.internal.loader.URLClassPath may leak JarFile instance when dealing with unexpected Class-Path entry in manifest

Reviewed-by: michaelm, cstein, alanb

! src/java.base/share/classes/jdk/internal/loader/URLClassPath.java
+ test/jdk/java/net/URLClassLoader/JarLoaderCloseTest.java

Changeset: 1ff9ac72
Branch: hermetic-java-runtime
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-08-28 10:22:34 +0000
URL:       https://git.openjdk.org/leyden/commit/1ff9ac7233d51a58fd54a92d2c45761478574cc7

8338731: MemoryLayout::offsetHandle can return a negative offset

Reviewed-by: pminborg, psandoz

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

Changeset: 21505216
Branch: hermetic-java-runtime
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Pavel Rappo <prappo at openjdk.org>
Date:      2024-08-28 11:01:15 +0000
URL:       https://git.openjdk.org/leyden/commit/2150521650d6b730cfe9d3ecb91d589c96862475

8322036: Improve help output from the javadoc tool

Reviewed-by: prappo

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOptions.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties

Changeset: 9d183bd0
Branch: hermetic-java-runtime
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2024-08-28 12:19:58 +0000
URL:       https://git.openjdk.org/leyden/commit/9d183bd02763ee4ff5aa8388e039d8b5a6964328

8339149: jfr_flush_event_writer - return value type mismatch

Reviewed-by: egahlin

! src/hotspot/share/jfr/jni/jfrJniMethod.hpp

Changeset: 32c97509
Branch: hermetic-java-runtime
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-08-28 13:28:01 +0000
URL:       https://git.openjdk.org/leyden/commit/32c975098521e830ce706b67e7232a007c0846c7

8339160: [BACKOUT] JDK-8338440 Parallel: Improve fragmentation mitigation in Full GC

Reviewed-by: tschatzl

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

Changeset: b6700095
Branch: hermetic-java-runtime
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Date:      2024-08-28 15:23:50 +0000
URL:       https://git.openjdk.org/leyden/commit/b6700095c018a67a55b746cd4eee763c68f538e0

8338729: Retire the test jdk/java/util/zip/TestZipError.java

Reviewed-by: lancea

- test/jdk/java/util/zip/TestZipError.java

Changeset: 379f3db0
Branch: hermetic-java-runtime
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2024-08-28 16:47:30 +0000
URL:       https://git.openjdk.org/leyden/commit/379f3db001fe4bffd3a00e0363a98275e7b2eba8

8339175: ProblemList runtime/interpreter/LastJsrTest.java on all platforms with Xcomp

Reviewed-by: matsaave

! test/hotspot/jtreg/ProblemList-Xcomp.txt
! test/hotspot/jtreg/ProblemList.txt

Changeset: 0c2b1758
Branch: hermetic-java-runtime
Author:    Anthony Scarpino <ascarpino at openjdk.org>
Date:      2024-08-28 17:24:33 +0000
URL:       https://git.openjdk.org/leyden/commit/0c2b175898d13b58ffe56e2f9cbc9d88173a61cf

8328608: Multiple NewSessionTicket support for TLS

Reviewed-by: djelinski

! src/java.base/share/classes/sun/security/ssl/Finished.java
! src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java
! src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java
! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java
! src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java
! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java
! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/java.base/share/classes/sun/security/util/Cache.java
! test/jdk/javax/net/ssl/SSLSession/CertMsgCheck.java
! test/jdk/javax/net/ssl/SSLSession/CheckSessionContext.java
! test/jdk/javax/net/ssl/templates/TLSBase.java
+ test/jdk/sun/security/ssl/SSLSessionImpl/MultiNSTClient.java
+ test/jdk/sun/security/ssl/SSLSessionImpl/MultiNSTNoSessionCreation.java
+ test/jdk/sun/security/ssl/SSLSessionImpl/MultiNSTParallel.java
+ test/jdk/sun/security/ssl/SSLSessionImpl/MultiNSTSequence.java

Changeset: 3d49fb8a
Branch: hermetic-java-runtime
Author:    Manukumar V S <mvs at openjdk.org>
Date:      2024-08-28 17:54:43 +0000
URL:       https://git.openjdk.org/leyden/commit/3d49fb8a17ceec6e23595bc8affc89765899f72b

8338103: Stabilize and open source a Swing OGL ButtonResizeTest

Reviewed-by: abhiscxk, prr, tr

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

Changeset: a98ecad0
Branch: hermetic-java-runtime
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-08-28 18:16:00 +0000
URL:       https://git.openjdk.org/leyden/commit/a98ecad0a920f12d81386de3d0f549d542014773

8338897: Small startup regression remains after JDK-8309622 and JDK-8331932

Reviewed-by: liach, naoto

! src/java.base/share/classes/java/util/Locale.java
! src/java.base/share/classes/sun/util/locale/BaseLocale.java

Changeset: eff6d9cd
Branch: hermetic-java-runtime
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-08-28 18:22:30 +0000
URL:       https://git.openjdk.org/leyden/commit/eff6d9cd23f9da8720a44ad628aa0a3e6f58facf

8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce boxing overheads

Reviewed-by: liach

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

Changeset: d03ec7aa
Branch: hermetic-java-runtime
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-08-28 20:17:25 +0000
URL:       https://git.openjdk.org/leyden/commit/d03ec7aad41d830b47801b7af75ee5e278128e69

8339030: frame::print_value_on(outputStream* st, JavaThread *thread) doesn't need thread argument

Reviewed-by: dholmes, coleenp

! src/hotspot/share/oops/instanceStackChunkKlass.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/continuationFreezeThaw.cpp
! src/hotspot/share/runtime/frame.cpp
! src/hotspot/share/runtime/frame.hpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/vframe.cpp

Changeset: d08b5bd9
Branch: hermetic-java-runtime
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-08-28 20:18:51 +0000
URL:       https://git.openjdk.org/leyden/commit/d08b5bd9f5f740d75c1acfbd644ce1c822e03833

8258483: [TESTBUG] gtest CollectorPolicy.young_scaled_initial_ergo_vm fails if heap is too small

Reviewed-by: ayang

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

Changeset: a8ac2872
Branch: hermetic-java-runtime
Author:    Justin Lu <jlu at openjdk.org>
Date:      2024-08-28 21:14:29 +0000
URL:       https://git.openjdk.org/leyden/commit/a8ac28725bfc22867c76856ddce094588a97b84c

8339126: JNI exception pending in Inflater.c

Reviewed-by: lancea, vtewari, jpai, naoto

! src/java.base/share/native/libzip/Inflater.c

Changeset: 72a49005
Branch: hermetic-java-runtime
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-08-28 21:16:18 +0000
URL:       https://git.openjdk.org/leyden/commit/72a49005ee8c4aeb6dcf3eff4c56576a2b4d0081

8338888: SystemDictionary::class_name_symbol has incorrect length check

Reviewed-by: stuefe, kbarrett, coleenp

! src/hotspot/share/classfile/systemDictionary.cpp
! test/hotspot/jtreg/runtime/exceptionMsgs/NoClassDefFoundError/NoClassDefFoundErrorTest.java
! test/hotspot/jtreg/runtime/exceptionMsgs/NoClassDefFoundError/libNoClassDefFoundErrorTest.c

Changeset: 26e3d535
Branch: hermetic-java-runtime
Author:    Brent Christian <bchristi at openjdk.org>
Date:      2024-08-28 22:54:38 +0000
URL:       https://git.openjdk.org/leyden/commit/26e3d535ad4d6e5d78ca50941cfa39dd337892a9

8338716: Re-visit "interrupt handling" in jdk.internal.loader.Resource

Reviewed-by: alanb

! src/java.base/share/classes/jdk/internal/loader/Resource.java

Changeset: 0ddcd701
Branch: hermetic-java-runtime
Author:    Dean Long <dlong at openjdk.org>
Date:      2024-08-29 00:34:11 +0000
URL:       https://git.openjdk.org/leyden/commit/0ddcd7017576a0f9c97a74b7d47624ae06ed06d6

8335120: assert(!target->can_be_statically_bound() || target == cha_monomorphic_target) failed

Reviewed-by: kvn, vlivanov

! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciMethod.hpp

Changeset: eb7ead58
Branch: hermetic-java-runtime
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-08-29 05:03:15 +0000
URL:       https://git.openjdk.org/leyden/commit/eb7ead58fd70822669d2aa1a0053814e58955f82

8336873: BasicSplitPaneDivider:oneTouchExpandableChanged() should mention that implementation depends on SplitPane.supportsOneTouchButtons property

Reviewed-by: prr, abhiscxk

! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java

Changeset: 1383fec4
Branch: hermetic-java-runtime
Author:    Kangcheng Xu <kxu at openjdk.org>
Date:      2024-08-29 05:34:08 +0000
URL:       https://git.openjdk.org/leyden/commit/1383fec41756322bf2832c55633e46395b937b40

8327381: Refactor type-improving transformations in BoolNode::Ideal to BoolNode::Value

Reviewed-by: chagedorn, thartmann, jkarthikeyan, epeter

! src/hotspot/share/opto/subnode.cpp
! src/hotspot/share/opto/subnode.hpp
+ test/hotspot/jtreg/compiler/c2/gvn/TestBoolNodeGVN.java
! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java

Changeset: 0b4a7d53
Branch: hermetic-java-runtime
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-08-29 06:25:27 +0000
URL:       https://git.openjdk.org/leyden/commit/0b4a7d534204b7b3b041f5117282dd13b1c7c62f

8324859: Improve error recovery

Reviewed-by: mcimadamore

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

Changeset: ff59532d
Branch: hermetic-java-runtime
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-08-29 06:28:05 +0000
URL:       https://git.openjdk.org/leyden/commit/ff59532ddd3002df61e46d58b3f29d26c78295da

8338678: Erroneous parameterized type represented as <any>

Reviewed-by: vromero

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

Changeset: f080b4bb
Branch: hermetic-java-runtime
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-08-29 07:07:12 +0000
URL:       https://git.openjdk.org/leyden/commit/f080b4bb8a75284db1b6037f8c00ef3b1ef1add1

8333098: ubsan: bytecodeInfo.cpp:318:59: runtime error: division by zero

Reviewed-by: kvn, iveresov

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

Changeset: 362f9ce0
Branch: hermetic-java-runtime
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-08-29 07:29:12 +0000
URL:       https://git.openjdk.org/leyden/commit/362f9ce077baa900ed81a0473ec0187efde132ef

8339120: Use more fine-granular gcc unused warnings

Reviewed-by: jwaters, kbarrett, erikj

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

Changeset: 723588a4
Branch: hermetic-java-runtime
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-08-29 08:54:02 +0000
URL:       https://git.openjdk.org/leyden/commit/723588a4e78d25f0ef3c4cdaeb377aedc3a352d4

8338569: HTTP/1.1 CleanupTrigger may be triggerred after the next exchange started

Reviewed-by: jpai

! src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
! src/java.net.http/share/classes/jdk/internal/net/http/SocketTube.java
! src/java.net.http/share/classes/jdk/internal/net/http/common/FlowTube.java
! test/jdk/java/net/httpclient/DigestEchoClient.java
! test/jdk/java/net/httpclient/ShutdownNow.java
! test/jdk/java/net/httpclient/SmokeTest.java

Changeset: d35ffa4f
Branch: hermetic-java-runtime
Author:    Andrey Turbanov <aturbanov at openjdk.org>
Date:      2024-08-29 09:57:52 +0000
URL:       https://git.openjdk.org/leyden/commit/d35ffa4f6afb7df052103cee8544e4e707b72cc1

8339017: Make a couple of fields in DoubleByte static

Reviewed-by: bpb, naoto

! src/java.base/share/classes/sun/nio/cs/DoubleByte.java

Changeset: 8c8b5801
Branch: hermetic-java-runtime
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-08-29 10:06:08 +0000
URL:       https://git.openjdk.org/leyden/commit/8c8b5801fd9d28a71edf3bd8d1fae857817e27de

8338281: jshell does not run shutdown hooks

Reviewed-by: asotona

! src/jdk.jshell/share/classes/jdk/jshell/execution/ExecutionControlForwarder.java
! src/jdk.jshell/share/classes/jdk/jshell/execution/JdiDefaultExecutionControl.java
! test/langtools/jdk/jshell/ShutdownTest.java

Changeset: e57b5932
Branch: hermetic-java-runtime
Author:    Johan Sj?len <jsjolen at openjdk.org>
Date:      2024-08-29 11:23:04 +0000
URL:       https://git.openjdk.org/leyden/commit/e57b59325831247818cb4b07c4fd43e4556effca

8335062: NMT: Make StackIndex non-opaque

Reviewed-by: stuefe, gziemski

! src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp
! src/hotspot/share/nmt/vmatree.hpp
! test/hotspot/gtest/nmt/test_nmt_nativecallstackstorage.cpp

Changeset: 777ed2b5
Branch: hermetic-java-runtime
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-08-29 15:45:52 +0000
URL:       https://git.openjdk.org/leyden/commit/777ed2b5d2ef8371407cc9bf0370a7cef937cfb7

8339132: Make DirectCodeBuilder write through without allocating instruction objects

Reviewed-by: asotona, redestad

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

Changeset: a4962ace
Branch: hermetic-java-runtime
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-08-29 20:38:52 +0000
URL:       https://git.openjdk.org/leyden/commit/a4962ace4d3afb36e9d6822a4f02a1515fac40ed

8338257: UTF8 lengths should be size_t not int

Reviewed-by: stuefe, coleenp, dlong

! src/hotspot/share/classfile/compactHashtable.cpp
! src/hotspot/share/classfile/compactHashtable.hpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/classfile/modules.cpp
! src/hotspot/share/classfile/stringTable.cpp
! src/hotspot/share/classfile/symbolTable.cpp
! src/hotspot/share/jfr/dcmd/jfrDcmds.cpp
! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.cpp
! src/hotspot/share/oops/symbol.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvmtiEnv.cpp
! src/hotspot/share/services/finalizerService.cpp
! src/hotspot/share/utilities/utf8.cpp
! src/hotspot/share/utilities/utf8.hpp

Changeset: f2968b34
Branch: hermetic-java-runtime
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-08-29 21:06:05 +0000
URL:       https://git.openjdk.org/leyden/commit/f2968b34a55009fb195e381ffa615488974e9ba6

8339020: Remove unused HeapShared::calculate_oopmap

Reviewed-by: coleenp

! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/heapShared.hpp

Changeset: b711c41d
Branch: hermetic-java-runtime
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-08-29 21:21:16 +0000
URL:       https://git.openjdk.org/leyden/commit/b711c41d442fc369a84745c0203db638e0b7e671

8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long

Reviewed-by: liach, redestad

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

Changeset: 2ea61c7b
Branch: hermetic-java-runtime
Author:    Jiangli Zhou <jianglizhou at google.com>
Date:      2024-08-29 16:25:53 +0000
URL:       https://git.openjdk.org/leyden/commit/2ea61c7b93004b21e1950a768839e8f1e0aee1b9

Merge branch 'master' into hermetic-java-runtime

! make/modules/java.base/lib/CoreLibraries.gmk
! make/modules/java.base/lib/CoreLibraries.gmk


From duke at openjdk.org  Fri Aug 30 05:11:17 2024
From: duke at openjdk.org (duke)
Date: Fri, 30 Aug 2024 05:11:17 GMT
Subject: git: openjdk/leyden: premain: Experimental feature to allow special
 instrumentation code to be executed during training run. See
 CacheOnlyClassesIn.java for details
Message-ID: <b3a118df-0a2f-41fa-96f3-8b84e25506f9@openjdk.org>

Changeset: 9bab6122
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-08-29 22:10:30 +0000
URL:       https://git.openjdk.org/leyden/commit/9bab6122728d62095207026a07ca5c49fac9dbd6

Experimental feature to allow special instrumentation code to be executed during training run. See CacheOnlyClassesIn.java for details

! src/hotspot/share/cds/cds_globals.hpp
! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/classLoaderExt.cpp
! src/hotspot/share/classfile/classLoaderExt.hpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/utilities/classpathStream.hpp
+ test/hotspot/jtreg/runtime/cds/appcds/leyden/CacheOnlyClassesIn.java